Re: Linux 2.6.32-rc3

Ingo Molnar
2009-10-06T16:31:13Z

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

> Unless:
>
> > _That_ i think is a lot harder to confuse with the real .31 than a
> > v2.6.31-1234-g16123c4 version string.
>
> .. are you saying that it would be just some automatically generated
> thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a
> CONFIG_LOCALVERSION_AUTO_SHORTFORM?

Yes, exactly. Not a Makefile or tag property, obviously.

> If so, then I don't hate "v2.6.31+", but at the same time, that single
> plus-sign tells _so_much_ less than v2.6.31-1234-g16123c4 that I think
> it's really sad and crippled.

Agreed, and in my internal testing i've made LOCALVERSION_AUTO
compulsory long time ago.

But at least to me there's a simple benchmark: i have been confused by
this. In one of the merge windows i thought i booted .31 vanilla while
in fact it was a few days into the merge window already. Took me a few
minutes to figure out why it was crashing ;-)

YMMV.

Maybe a variant of the full string:

v2.6.31+1234-g16123c4

would be even less confusing. I tend to ignore dashes sub-consciously
(as a 'minor versions' kind of thing) - while in this ~1 week out of the
9 weeks of your tree's cycle it means something much more than that, and
we dont emphasise the difference strongly enough.

But ... that's just my own experience. I also see -tip users become a
lot more cautious for a few rc's once we go -rc1 - while they happily
test things in the merge window (which is _way_ more dangerous than
pretty much any post-rc1 tree you push out).

Basically IMHO the inflection point between v2.6.31 and the merge window
is way too 'smooth', and not obviously so, and it lures people who are
not careful enough into testing something they probably wouldnt test
otherwise. It's a purely human thing - to a machine it's already very
obvious what g16123c4 means - it doesnt need any of the fancy v2.6.31
stuff either.

Ingo