From: Lee Jones <lee.jones@linaro.org>
To: Tejun Heo <tj@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, alexandre.torgue@st.com,
linux-ide@vger.kernel.org, hdegoede@redhat.com
Subject: Re: [PATCH 3/3] ahci: st: Add support for ST's SATA IP
Date: Wed, 19 Feb 2014 17:24:43 +0000 [thread overview]
Message-ID: <20140219172443.GJ10504@lee--X1> (raw)
In-Reply-To: <20140219170037.GK10134@htj.dyndns.org>
> > Again, that's not what I said. It's great that your subsystem is being
> > improved, but insisting that anyone who submits new code to rebase
> > on top of some development patches which only exist in mail form, and
> > refusing to take patches until they do so doesn't seem right to me.
>
> No policy is perfect and nothing can be decided solely on single
> policy. There of course are trade-offs to make depending on the
> specific circumstances. The problem, here, is that what has been
> going on is skewed towards one extreme and has potential to develop
> into a fairly large mess if left uncorrected.
>
> The message I've been sending out has been pretty clear. There are
> multiple people duplicating about the same thing in their drivers.
> Fortunately, Hans' refactoring is pretty close to completion and
> should help simplifying most of them. I'm not even asking you to do
> the bulk of work. Just take a look at it and help / push if you can.
> It may be unfortunate that the circumstances haven't been completely
> aligned for your convenience but that's what needs to be done to keep
> things sustainable.
I understand this. Thanks for taking the time to explain properly.
FWIW, I have now managed to rebase the driver on top of Hans' work and
I am now in the process of converting it to the new way of working.
> This is a collaborative work and what I asked you isn't some
> insurmountable amount of extra work. It's just beyond me that your
> response is "it's not fair". No wonder the whole thing has been
> drifting towards mess. That's not how this works. Judging from your
> linaro address, I assume you have been involved with some upstream
> work, how can this possibly be your response? Such attitude is
> actively harmful and has no place in upstream development.
>
> Again, of course, there can be trade-offs. We sometimes do need to
> take termporal hits in maintainability for faster hardware enablement
> or whatnot; however, we can't do that without trust that the people
> dumping stuff which needs later cleanups would actually help.
> Unfortnately, I have close to zero trust given the recent developments
> and your "it's not fair, that's not my responsibility" attitude
> clearly confirms the conclusion.
>
> So, please take long look at how you perceive upstream development.
> It's a collaborative process. Other people don't owe you by default.
Please refrain from adding quotation marks around things I didn't
actually say. I didn't say that this whole process was unfair. I was
pertaining to the fact that requesting that a driver is converted to a
non-existing API was wrong. As it currently stands the driver uses the
correct one. I also said that I'd happily convert it over when the
clean-ups are actually applied.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
WARNING: multiple messages have this Message-ID (diff)
From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] ahci: st: Add support for ST's SATA IP
Date: Wed, 19 Feb 2014 17:24:43 +0000 [thread overview]
Message-ID: <20140219172443.GJ10504@lee--X1> (raw)
In-Reply-To: <20140219170037.GK10134@htj.dyndns.org>
> > Again, that's not what I said. It's great that your subsystem is being
> > improved, but insisting that anyone who submits new code to rebase
> > on top of some development patches which only exist in mail form, and
> > refusing to take patches until they do so doesn't seem right to me.
>
> No policy is perfect and nothing can be decided solely on single
> policy. There of course are trade-offs to make depending on the
> specific circumstances. The problem, here, is that what has been
> going on is skewed towards one extreme and has potential to develop
> into a fairly large mess if left uncorrected.
>
> The message I've been sending out has been pretty clear. There are
> multiple people duplicating about the same thing in their drivers.
> Fortunately, Hans' refactoring is pretty close to completion and
> should help simplifying most of them. I'm not even asking you to do
> the bulk of work. Just take a look at it and help / push if you can.
> It may be unfortunate that the circumstances haven't been completely
> aligned for your convenience but that's what needs to be done to keep
> things sustainable.
I understand this. Thanks for taking the time to explain properly.
FWIW, I have now managed to rebase the driver on top of Hans' work and
I am now in the process of converting it to the new way of working.
> This is a collaborative work and what I asked you isn't some
> insurmountable amount of extra work. It's just beyond me that your
> response is "it's not fair". No wonder the whole thing has been
> drifting towards mess. That's not how this works. Judging from your
> linaro address, I assume you have been involved with some upstream
> work, how can this possibly be your response? Such attitude is
> actively harmful and has no place in upstream development.
>
> Again, of course, there can be trade-offs. We sometimes do need to
> take termporal hits in maintainability for faster hardware enablement
> or whatnot; however, we can't do that without trust that the people
> dumping stuff which needs later cleanups would actually help.
> Unfortnately, I have close to zero trust given the recent developments
> and your "it's not fair, that's not my responsibility" attitude
> clearly confirms the conclusion.
>
> So, please take long look at how you perceive upstream development.
> It's a collaborative process. Other people don't owe you by default.
Please refrain from adding quotation marks around things I didn't
actually say. I didn't say that this whole process was unfair. I was
pertaining to the fact that requesting that a driver is converted to a
non-existing API was wrong. As it currently stands the driver uses the
correct one. I also said that I'd happily convert it over when the
clean-ups are actually applied.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2014-02-19 17:24 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-17 12:56 [PATCH 1/3] ahci: st: Provide DT bindings for ST's SATA implementation Lee Jones
2014-02-17 12:56 ` Lee Jones
2014-02-17 12:56 ` [PATCH 2/3] ARM: DT: STi: Add DT node for ST's SATA device Lee Jones
2014-02-17 12:56 ` Lee Jones
2014-02-17 12:56 ` [PATCH 3/3] ahci: st: Add support for ST's SATA IP Lee Jones
2014-02-17 12:56 ` Lee Jones
2014-02-18 23:36 ` Tejun Heo
2014-02-18 23:36 ` Tejun Heo
2014-02-19 8:30 ` Lee Jones
2014-02-19 8:30 ` Lee Jones
2014-02-19 14:04 ` Tejun Heo
2014-02-19 14:04 ` Tejun Heo
2014-02-19 15:01 ` Lee Jones
2014-02-19 15:01 ` Lee Jones
2014-02-19 15:06 ` Tejun Heo
2014-02-19 15:06 ` Tejun Heo
2014-02-19 15:23 ` Lee Jones
2014-02-19 15:23 ` Lee Jones
2014-02-19 15:36 ` Tejun Heo
2014-02-19 15:36 ` Tejun Heo
2014-02-19 16:39 ` Lee Jones
2014-02-19 16:39 ` Lee Jones
2014-02-19 17:00 ` Tejun Heo
2014-02-19 17:00 ` Tejun Heo
2014-02-19 17:24 ` Lee Jones [this message]
2014-02-19 17:24 ` Lee Jones
2014-02-19 17:26 ` Tejun Heo
2014-02-19 17:26 ` Tejun Heo
2014-02-19 17:40 ` Lee Jones
2014-02-19 17:40 ` Lee Jones
2014-02-19 18:06 ` Tejun Heo
2014-02-19 18:06 ` Tejun Heo
2014-02-19 11:54 ` Hans de Goede
2014-02-19 11:54 ` Hans de Goede
2014-02-19 11:54 ` Hans de Goede
2014-02-19 12:14 ` Lee Jones
2014-02-19 12:14 ` Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140219172443.GJ10504@lee--X1 \
--to=lee.jones@linaro.org \
--cc=alexandre.torgue@st.com \
--cc=hdegoede@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.