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

Takashi Iwai tiwai at suse.de
Mon Jul 29 16:46:47 UTC 2013


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.


Takashi


More information about the Ksummit-2013-discuss mailing list