[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