[Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process

[Paul Gortmaker]

On 13-07-29 01:36 PM, Jason Cooper wrote:
> On Mon, Jul 29, 2013 at 10:16:27AM -0700, Greg KH wrote:
>> On Mon, Jul 29, 2013 at 06:39:43PM +0200, Jiri Kosina wrote:
>>> On Mon, 29 Jul 2013, Takashi Iwai wrote:
>>>
>>>> In the case of stable kernels, there is a review phase, where the
>>>> patches aren't committed to the git tree yet.  It happens often that
>>>> inappropriate patches are dropped during it.  If the processing is
>>>> changed to use a git pull, we'll have to add a revert commit instead
>>>> of dropping a patch, which is messy as a stable tree.  This is a
>>>> disadvantage of git pull, at least.
>>>
>>> The merit of my proposal really is about shifting the responsibility.
>>>
>>> Stable team is now sending patches (collected in a rather fuzzy way) out 
>>> for review, and they get passively approved. It's not clear who is then 
>>> responsible for the patch having been applied to -stable. Is the the patch 
>>> author, is it someone in the SOB chain, is it stable team?
>>
>> Does it matter where they all come from?  I get patches from all sorts
>> of places today:
>> 	- cc: stable@ in patch
>> 	- maintainers email me with git commits to include
>> 	- developers email git commit ids to stable@ mailing list for
>> 	  bugs they have hit, or patches they have found in distro
>> 	  kernel trees (Ben did a wonderful job with digging through Red
>> 	  Hat's kernel and sending the patches found there.)
>> 	- I look at distro kernel trees and pick the same patches they
>> 	  have in there
>> 	- I dig through the kernel tree and find patches to apply for
>> 	  areas where I have problems with hardware / device ids.
>> 	- I skim all patches applied to Linus's tree (they all go a
>> 	  mailing list, making it easy to do so) and pick the ones that
>> 	  look like "obvious" fixes / new devices ids.
>>
>>> With pull requests, there is a person who can be clearly identified as 
>>> responsible -- the maintainer (with stable team also having their portion 
>>> of responsibility of course for actually pulling the branch).
>>
>> So you now cut out all of the above ways to get patches into the stable
>> tree, with the exception of the first one.  Suddenly you just reduced
>> the amount of patches in the stable releases by a _lot_.  Is that a good
>> thing to do?
>>
>> Again, I DO NOT want to put ANY extra burden on maintainers to have to
>> do anything more than add a simple line to a patch in order to get it
>> into the kernel tree.  Requiring them to send me git pull requests is
>> going to add to their development burden, and reduce the number of
>> patches in the stable releases by a lot, making them less useful.
> 
> I don't think there is any need to *require* maintainers to do pull
> requests.  But for those that choose to do so, it would be great if we
> could figure out the process so that the advantages of doing the PR are

Not sure what you mean by "figure out the process".  The maintainer
groups patches together in one mechanism or another (patchworks, a
list of commit IDs, etc) and gives that to Greg.  Any additional
detail on that is just semantics.  And if they don't want the direct
ownership, they can use one of the other methods Greg lists -- several
of which I've taken advantage of myself.

> not lost.  Particularly, common commit ids, and trackability.

You won't get common commit IDs.  There already is the boilerplate 1st
line in each saying 'commit abcd1234f... upstream" which achieves the
mapping.  See below why that is generally as good as it gets.

> 
> Would it be possible for patches developers think are candidates for
> -stable inclusion be sent to the stable mailinglist before they are in
> tree?  Then, if the stable maintainers feel it's appropriate for
> -stable, they'll give and 'Acked-by: <...> # v3.10.x'.  At that point,
> the subsystem maintainer can put it in a branch to be pulled into Linus'
> tree and then into the appropriate -stable tree.

No. Won't work.  You'd be asking the maintainer to put the commit on
the lowest common denominator for all stable releases.  And then be
asking Linus to pull little fragmented branches with v2.6.32 as their
baseline commit -- pushing the work of a "forward port" onto the hands
of the person doing the merge.  Plus we generally want the commit to
look roughly applicable to the rc1 release it is merged into, which
means the backporting work (if any) has to land on the person wanting
to do the stable backport.  And if the backport is non-trivial, then
that is a darn good sign that they seriously might want to consider
the applicability of that commit to the old release.  It was one of
the metrics that I sure considered.

Aside from perhaps extending the review window to be a bit more than
48h, I'm inclined to think there are a lot of solutions here that
are simply looking for a problem.

Paul.
--

> 
> thx,
> 
> Jason.
> _______________________________________________
> Ksummit-2013-discuss mailing list
> Ksummit-2013-discuss at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-2013-discuss
> 
>