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

[Ingo Molnar]

FYI, today i committed a scheduler performance fix that has a number of 
commit prerequisites for -stable integration. Those commits are not 
marked -stable.

Previously, in similar situations, i solved it by email-forwarding the 
prereq commits to stable@xxxxxxxxxxx (or by waiting for your 'it does 
not apply to -stable' email and figuring out the prereqs then.)

But we can move this into the Git commit space too, and minimize the 
work for the -stable team, via a new -stable tag variant. So with this 
new commit i started using a new tagging scheme in the commit itself:

 Cc: <stable@xxxxxxxxxx> # .32.x: a1f84a3: sched: Check for an idle shared cache
 Cc: <stable@xxxxxxxxxx> # .32.x: 1b9508f: sched: Rate-limit newidle
 Cc: <stable@xxxxxxxxxx> # .32.x: fd21073: sched: Fix affinity logic
 Cc: <stable@xxxxxxxxxx> # .32.x
 LKML-Reference: <1257821402.5648.17.camel@xxxxxxxxxxxxxxxx>
 Signed-off-by: Ingo Molnar <mingo@xxxxxxx>

The tag sequence has the meaning of:

  git cherry-pick a1f84a3
  git cherry-pick 1b9508f
  git cherry-pick fd21073
  git cherry-pick <this commit>

and i'm wondering whether this tagging scheme is fine with your -stable 
scripting, etc.

A further question is, i can see using this tagging scheme in the future 
in merge commits log messages too - will your scripts notice that too?

For example if there's a few commits left in tip:*/urgent branches 
(tip:sched/urgent, tip:core/urgent, tip:x86/urgent, etc.) by the time 
v2.6.32 is released, i will then merge them into tip:sched/core, 
tip:core/core, tip:x86/core, etc. - and i could use the merge commit as 
a notification area to 'activate' them for -stable backporting via a 
merge commit.

This is how such merge commits would look like:

  Merge branch 'core/urgent' into core/rcu

  Merge reason: Pick up urgent fixes that did not make it into .32.0

  Cc: <stable@xxxxxxxxxx> # .32.x: 83f5b01: rcu: Fix long-grace-period race
  Signed-off-by: Ingo Molnar <mingo@xxxxxxx>

This is not so rare of a situation as it might seem - for the trees i 
maintain it happens in almost every release cycle - i typically skip 
urgent branch merges after -rc8/-rc9, unless they are very-very-urgent 
fixes - but they'd still be eligible for -stable.

I've attached the full commit below. The prereq commits are not uptream 
yet, and they dont carry a -stable backporting tag as the -stable 
relevance was not anticipated at that point yet. They will all be 
upstream in the next merge window when Linus merges the relevant tree - 
and then all these tags become visible to the -stable team's scripts.

What do you think about this new -stable tagging variant? To me it looks 
quite intuitive, less error-prone and it is more informative as well. 
Furthermore, it gives us some freedom to mark commits as backport 
candidates later on. I kept them oneliners for the purpose of making 
them all self-sufficient tags.

( Sidenote: i wouldnt go as far as to generate null Git commits to mark
  backports after the fact - this scheme is for a series of commits that 
  get 'completed' - there's usually a final followup commit that can 
  embedd this information. )

	Ingo

---------------------------->