Re: Linux 2.6.32-rc3

Ingo Molnar
2009-10-06T14:46:24Z

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> So no. I'm not going to do -rc0. Because doing that is _stupid_. And
> until you understand _why_ it's stupid, it's pointless talking about
> it, and when you _do_ understand that it's stupid, you'll agree with
> me.

I understand non-linear history, but still i think that it might make
sense to make it more apparent that the tree people pull from you after
.31 got released is a lot closer to what .32 is going to be than to .31.
(which the name implies)

I.e. i think it's a fact that right now our release version is highly
deceptive during the merge window. Two days into the merge window and we
have more commits added than we add from .31-rc7 to .31-rc9 total. A
week into the merge window we have .31 + 6000 commits merged and still
call it v2.6.31, to the casual looker.

We can ignore that and say "hehe, you dont understand non-linear trees
and ran git remote update blindly, too bad for you", or we might do
something to make things more transparent and reduce the confusion.
Personally i really want people to try our git trees, but them also be
fully aware of the risks involved.

One option would be to make LOCALVERSION_AUTO compulsory.

Or to add a tweak to the naming, something like:

v2.6.31
v2.6.31+
v2.6.32-rc1
v2.6.32-rc1+
..
v2.6.32-rc9
v2.6.32-rc9+
v2.6.32

Would make it clear what's going on, even in the simplified world of
limited-size version numbers.

Or, IMHO it would also be a valid naming model to do this small tweak to
the above naming scheme:

v2.6.31
v2.6.32-rc0
v2.6.32-rc0+
v2.6.32-rc1
v2.6.32-rc1+
..
v2.6.32-rc9
v2.6.32-rc9+
v2.6.32

... for the sole purpose of warning people that anything they pull after
v2.6.31 got released is (wildly!) not vanilla v2.6.31 anymore. Not more,
not less.

Am i confused? :-)

Ingo