linux-kernel - Re: Linux 2.6.32-rc3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 6 Oct 2009 08:42:18 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Dirk Hohndel <hohndel@...radead.org>, Len Brown <lenb@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.32-rc3

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/