Messages in this thread | | | Date | Tue, 10 Nov 2009 21:45:37 +0100 | From | Ingo Molnar <> | Subject | Re: [RFC] new -stable tag variant, Git workflow question |
| |
* Greg KH <gregkh@suse.de> 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. > > 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.
Yeah. This new tagging scheme doesnt really allow anything 'new' per se - it just helps the existing practice some more. All these commits were -stable candidates anyway, in exactly the same order - the only difference the new tagging scheme adds here is a more organized, in-upsream-Git way of communicating it to you.
This is also easier and less error prone for me than using email: i can do all the -stable tagging when i create a commit - or if i see that a commit has prereqs and those should be in -stable too. In those situations i check out the last stable kernel version, and cherry-pick the prereqs and the target commit, to see that it cherry-picks without conflicts.
But i cannot send you an email to stable@kernel.org just yet: as i havent fully tested the last commit yet, and have not pushed it out yet. The commit ID is not stable yet.
So without the in-commit tagging, i'd have to remember to send you an email in an hour (or in a day - whenever testing is done) - and that is error prone and easy to forget. The prereqs might be lost, etc. It's better to do this all in one well-focused moment of time, gather the information and mention it in the changelog.
Ingo
| |