lists.openwall.net | 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
| ||
|
Date: Tue, 10 Nov 2009 22:20:59 +0100 From: Ingo Molnar <mingo@...e.hu> To: Chris Friesen <cfriesen@...tel.com> Cc: Stefan Richter <stefanr@...6.in-berlin.de>, James Bottomley <James.Bottomley@...senPartnership.com>, Greg KH <gregkh@...e.de>, Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton <akpm@...ux-foundation.org>, Chris Wright <chrisw@...s-sol.org>, linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, "H. Peter Anvin" <hpa@...or.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl> Subject: Re: [RFC] new -stable tag variant, Git workflow question * Chris Friesen <cfriesen@...tel.com> wrote: > On 11/10/2009 09:52 AM, Stefan Richter wrote: > > > 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. > > Alternately, it's conceivable that the prerequisites were not > in-and-of-themselves candidates for -stable (maybe they didn't do > anything by themselves) but when combined with the final commit the > overall change is suitable for inclusion in -stable. Yeah. The way i do it as a maintainer is that when i add a new commit that i realize as a -stable candidate, and i know that it has no semantic prereqs (such as a new API, etc.), i git-cherry-pick it into stable in a test branch. If that works fine i mark it -stable straight away. If it conflicts, i figure out the prereqs, and look at those. If they are too big, or too risky, i often decide not to mark a patch for -stable backporting. (If it's not obvious to be in -stable then it should not be in -stable, almost by definition - a _LOT_ of people are using the stable kernels.) If the prereqs look sane and are wanted for -stable, i end up with a list of 2 or at most 3 commits that will cherry-pick cleanly. (rarely more than that - the 4 commits here are really an exception - they are a string of prereqs that are also fixes) I send that list of commits to stable@...nel.org. ( Sidenote: rarely does it make sense to port a conflicting commit to -stable. The risks of introducing some regression are just too high. Cherry-picking of commits, (while not entirely risk-free of course), is far more robust in practice. (conflicting backmerges do happen too occasionally, for high-profile bug fixes that justify the cost.) ) So this 'send the list to stable@...nel.org' step is simplified via these tags: Cc: <stable@...nel.org> # .32.x: a1f84a3: sched: Check for an idle shared cache Cc: <stable@...nel.org> # .32.x: 1b9508f: sched: Rate-limit newidle Cc: <stable@...nel.org> # .32.x: fd21073: sched: Fix affinity logic Cc: <stable@...nel.org> # .32.x I'd have done that via a plain email in any case - so this scheme does not enable anything new - it just simplifies the process and makes it a bit more robust. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists