Messages in this thread | | | Date | Tue, 10 Nov 2009 22:29:03 +0100 | From | Ingo Molnar <> | Subject | Re: [RFC] new -stable tag variant, Git workflow question |
| |
* Junio C Hamano <gitster@pobox.com> wrote:
> Ingo Molnar <mingo@elte.hu> writes: > > > 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. > > I am just a bystander, but if it were truly in-upstream-git way, > wouldn't you be forking a branch from the tagged target release (the > latest of 2.6.32.X), and queuing only the changes meant for -stable to > it, and giving the name of the branch to git people and sending out > patches from that branch for e-mailed review and application? > > There won't be any special tagging required, only a dedicated branch. > > Or am I missing something?
There's no Git flow towards -stable. It's either forwarded emails, or tags in the upstream kernel. Also, _only_ commits that were pulled by Linus are eligible for -stable.
So the pull requests all first go to Linus - then can any commit flow to -stable.
But even if it was possible to send pull requests to Greg, marking commits as -stable candidates is more natural in the commit log itself.
That informs people ('hey, that's a dangerous patch, dont mark it for -stable!!' or 'hey, why isnt this commit tagged to stable??'), and it also ensures it that only commits from Linus's tree flow towards -stable.
Ingo
| |