Re: [RFC] new -stable tag variant, Git workflow question

[Greg KH <gregkh@suse.de>]

On Tue, Nov 10, 2009 at 04:52:22PM +0100, Stefan Richter wrote:
> James Bottomley wrote:
> [...]
> >> On Tue, Nov 10, 2009 at 04:48:31AM +0100, Ingo Molnar wrote:
> >> > FYI, today i committed a scheduler performance fix that has a number of 
> >> > commit prerequisites for -stable integration. Those commits are not 
> >> > marked -stable.
> [...]
> >> > we can move this into the Git commit space too, and minimize the 
> >> > work for the -stable team, via a new -stable tag variant.
> [...]
> > The question is, how important is this?
> > 
> > One of the assumptions behind the current setup is that I assume
> > backports are independent (so the order of transmission doesn't matter
> > that much).  This isn't always true, but the exceptions tend to get
> > handled manually.  Part of what the above is requesting is an
> > implementation that starts to care about ordering.
> 
> More importantly, isn't this against the character of the -stable kernel
> branches as _safe and simple_ hotfix branches?
> 
> If a fix has a number of prerequisites which ar not -stable fixes
> themselves, then it is more than a hint that this fix is not really well
> suited for -stable.

Not true, we have been doing this kind of thing for quite some time now.
Sometimes it's just a simple "this patch cleans up the code, and the
second one fixes it in an obvious manner" type thing.  It is easier for
me and everyone else for us to apply 2 commits to the -stable tree,
instead of rewriting the second patch that actually does the fix and
hope I got it all correct in doing so.

It's also easier to review stuff, which is the most important thing.

thanks,

greg k-h