Re: Linux 2.6.32-rc3

Linus Torvalds
2009-10-06T15:44:21Z

On Tue, 6 Oct 2009, Linus Torvalds wrote:
>
> It's the "let's make that meaningful and misleading number be even _more_
^^^^^^^^^^
> misleading by making people think it has meaning" magical thinking that I
> hate.

That 'meaningful' was supposed to be a 'meaningless' of course.

The point really is that we have about 1 new version number per week, but
at the same time we have an average of one _thousand_ commits merged per
week. So at a glance, the Makefile version number doesn't mean very much.

But if the thousand commits we merged actually were nicely spread out in
between those version numbers, it would all work really beautifully. Sure,
the top-level version number would only give you a 1/1000 of the real
commit information, but hey, that's kind of what you'd want, isn't it? So
then the top-level Makefile version number would be meaningful and useful!

But that's not how it works. In fact, if we actually followed our own
release rules ("merge window is for merging code that was written before
the merge window even started"), no commits except for my merge commits
should actually have that last release in their Makefile at all!

Now, that's not actually true, because (a) people rebase and (b) even in
the absense of rebases I do merge with people like Andrew by email, so we
actually end up having statistics like these:

git rev-list v2.6.31..v2.6.32-rc1 |
while read a
do
git show $a:Makefile | grep SUBLEVEL.=
done | sort | uniq -c

resulting in

32 SUBLEVEL = 29
383 SUBLEVEL = 30
8795 SUBLEVEL = 31
1 SUBLEVEL = 32

which is actually a bit sad in itself (showing just _how_ many people
rebased their work on top of a release), but is still showing that we
actually had 32 new commits in there that were based on a 2.6.29 kernel

And what people are suggesting with a 2.6.32-rc0 would just lead to people
now rebasing their work NOT EVEN ON A RELEASE. They'd want to rebase it on
top of that made-up commit (2.6.32-rc0), so now from a development
standpoint that commit suddenly becomes more important than the release
itself.

Do you not see the insanity? We should have _less_ of this kind of
thinking, not more. At least rebasing on top of a release sounds sane. Not
this kind of "rebase on top of a magic Linus-commit" crap.

Linus