Re: [Ksummit-discuss] [CORE TOPIC] stable workflow

[Jiri Kosina <jkosina@suse.cz>]

On Fri, 2 May 2014, Steven Rostedt wrote:

> > Hmm, I don't see how maintainer cherry-picking into 'for-stable' branch is 
> > different from stable team cherry-picking from Linus' tree.
> 
> I think it's more a level of trust. IIRC (and Greg, please chime in
> here) there's been more than one instance that people would send Greg
> something for stable that hasn't hit mainline.

I am pretty sure that is happening quite often indeed ... I come across 
Greg's "form letter" respones rather regularly :)

> Moving to git pull requests may make it much more difficult to verify
> this.

The whole point of my proposal is moving much more responsibility to 
subsystem maintainers. I really do hope that whenever someone is trying to 
trick the stable rules, it's a random contributor and not a subsystem 
maintainer.

> > The rule that Linus' tree commit has to be referenced in the commit 
> > message (cherry-picking implies rebase anyway) can of course stay as-is, 
> > and is automatically verifiable.
> 
> Yeah, perhaps an automated way to verify git pull requests would work.
> Each commit would have to have a specific way to specify what commit it
> backported. 

This is more or less standardized now anyway.

> Then the tool could compare that commit with the commit in Linus's tree. 
> If it's too different, then it would not accept it and would require 
> manual intervention to allow it.
> 
> Now there's also the problem of not just matching what's in mainline,
> but also being something that should go to stable. It may be a feature
> and not a true bug fix. That would still require Greg (or who ever is
> maintaining the stable tree) to look over each change.

Works with Linus and merge window vs. post-merge-window pull requests 
(which is in principle the same), which are supposedly *MUCH* larger 
volume. Is there any reason this shouldn't work on a magnitudes smaller 
scale, which stable tree is?

Thanks,

-- 
Jiri Kosina
SUSE Labs