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

Greg KH greg at kroah.com
Mon Jul 29 17:18:45 UTC 2013


On Mon, Jul 29, 2013 at 06:46:47PM +0200, Takashi Iwai wrote:
> At Mon, 29 Jul 2013 18:39:43 +0200 (CEST),
> 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?
> > 
> > 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).
> > 
> > How the patches that end up in the for-stable branch are reviewed is 
> > completely up to the particular subsystem (and will very likely copy the 
> > review process that is happening in that particular subsystem for Linus' 
> > tree already).
> 
> Yeah, I understand this, and myself rather prefer it, too, as I
> already asked about it in ks-2012 discussion ML :)
> 
> My point is that it means a significant change of work flow with a
> slight disadvantage.

Again, if a subsystem wants to only have patches applied to the stable
tree, that come to me from the subsystem maintainer, either through a
git pull, or through email, I will do that today.  I do that for a
number of subsystems today already, for many years, with no problems
reported (networking, some filesystems, KVM, etc.)

So if it's an issue that a subsystem maintainer always wants to have the
"final word", that's great, I can do that now, no need to change any
work flows by anyone, except that maintainer.

Just let me know if you want to do this for your subsystem.

thanks,

greg k-h


More information about the Ksummit-2013-discuss mailing list