lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 10 Nov 2009 11:39:19 -0800
From:	Greg KH <>
To:	Stefan Richter <>
Cc:	James Bottomley <>,
	Ingo Molnar <>,
	Linus Torvalds <>,
	Andrew Morton <>,
	Chris Wright <>,, Thomas Gleixner <>,
	"H. Peter Anvin" <>,
	Peter Zijlstra <>
Subject: Re: [RFC] new -stable tag variant, Git workflow question

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.


greg k-h
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists