[Ksummit-discuss] [CORE TOPIC] stable workflow

Jan Kara jack at suse.cz
Fri May 2 22:16:32 UTC 2014


On Fri 02-05-14 22:12:50, Jiri Kosina wrote:
> On Fri, 2 May 2014, Steven Rostedt wrote:
> 
> > > I'd like to re-iterate my usual question / discussion topic of 
> > > responsibility distribution for -stable patches; my proposal again would 
> > > be to align the -stable tree workflow with Linus' tree workflow -- i.e. 
> > > subsystem maintainers preparing 'for-stable' branches and sending pull 
> > > requests to the stable team, instead of rather random cherry-picking of 
> > > the patches from the air as they fly by the stable team members.
> > 
> > But the stable tree has a distinct requirement of all patches having to
> > be first in mainline.
> > 
> > Having a pull request can allow people to sneak things in that may not
> > be in Linus's tree. That would be bad. The cherry-picking guarantees
> > that only changes that were in Linus's tree get into stable.
> 
> Hmm, I don't see how maintainer cherry-picking into 'for-stable' branch is 
> different from stable team cherry-picking from Linus' tree.
  So how things work in the areas I work in is that either a patch author
or the maintainer add CC stable to the patch and then it gets eventually
automatically propagated to the stable tree. I don't see how this is
practically different from the maintainer putting together a pull request.
In both cases the maintainer has control over what patches are going to
stable.

Now I understand that if there are more levels of maintainers & thus git
trees, the top level maintainer has much smaller control over what gets
tagged for stable (in theory he could inspect all the commits he's pulling
and verify sanity of stable tags but I understand not many people do this).
But is this what you are concerned about? Or are you concerned about people
sending Greg inappropriate requests to include stuff?

								Honza
-- 
Jan Kara <jack at suse.cz>
SUSE Labs, CR


More information about the Ksummit-discuss mailing list