lkml.org 
[lkml]   [2009]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.6.32-rc3

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

> On Tue, 6 Oct 2009, Ingo Molnar wrote:
> >
> > 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.
>
> You are missing the point.
>
> The only thing we can do is to teach people that the Makefile version
> isn't too important, and that it really doesn't tell very much.
>
> Trying to tweak it to make it somehow "more meaningful" is a BAD
> THING, because it continues to spoon-feed people a lie.
>
> The cake is a lie. In between kernel versions, you can't rely on the
> Makefile. You should teach yourself (and others) THAT, rather than
> trying to teach people to believe the lie even more.
>
> Once you start believing the lie, suddenly all the subtrees will start
> thinking that now _their_ kernel versions are bad, so now they'll
> start to want to make the same idiotic changes to their Makefiles, or
> maybe they'll decide that they don't want to pull tagged releases, but
> the "one after the tag so that they'll get the updated Makefile".
>
> And even if they don't do that idiocy, the whole "the version number
> is meaningful outside of releases" thing leads to brain damage.

hm, i think you ignored (or missed, or found irrelevant) my first
suggested variant:

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

The '+' sign says that it's more than .31.

That defuses the 'lie' of trying to linerize a multi-thousand-node graph
down into some catchy human-readable string pretty efficiently i think.
It doesnt tell us precisely what that '+' means - it could be goodness
or it could be badness.

_That_ i think is a lot harder to confuse with the real .31 than a
v2.6.31-1234-g16123c4 version string.

My tweak #2, adding -rc0 indeed brings in problems, it's too artificial
to do it right after .31 gets released - and if we dont do it then we
cannot do it later either. (so we cannot really do it)

[ It might bring in some advantages too btw. A pull request to you for a
tree that is -rc0 based means it got rebased straight in the merge
window => bad. Such a thing would be apparent at a glance. 'Good'
trees should be based on some known good version of the previous
stable kernel cycle. ]

Ingo


\
 
 \ /
  Last update: 2009-10-06 17:49    [W:0.152 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site