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]

Message-ID: <alpine.LFD.2.01.0910060705240.3432@localhost.localdomain>
Date:	Tue, 6 Oct 2009 07:18:52 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dirk Hohndel <hohndel@...radead.org>
cc:	Len Brown <lenb@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.32-rc3

On Mon, 5 Oct 2009, Dirk Hohndel wrote:
> On Mon, 2009-10-05 at 21:57 -0400, Len Brown wrote:
>
> > This could be clarified if you update Makefile on the 1st commit
> > after 2.6.X is frozen to simply be 2.6.Y-merge or 2.6.Y-rc0
> > or something.  Anything but 2.6.X.
> 
> I have seen this request many times and it seems to make perfect sense.

No. It makes perfect sense just because the people who think so don't 
think things through.

It doesn't help, for several reasons:

 - the step function of the Makefile change happens once per release, and 
   if you compile anything but releases, you can never rely on just the 
   revision. Was it a plain -rc, a plain release, or something in 
   between? You'll never know, just looking at the 2.6.x.y thing.

   In other words, you fundamentally have three choices:

    (a) be confused. Adding an "-rc0" won't help. You'll still be confused 
	in between releases about exactly what you're running.

    (b) use CONFIG_LOCALVERSION_AUTO=y

	Now, if 'uname -r' says 2.6.31, then you _know_ it's exactly 
	2.6.31 and nothing else. If it's a few commits after 2.6.31, it 
	will say something like '2.6.31-1-g752015d', and you know that 
	it's one commit after 2.6.31, and you'll know _which_ commit it is!

    (c) Don't compile anything but releases. 

   Those are the choices. 

 - An even _more_ fundamental reason: Linux development isn't linear. 
   There is not one "first commit" after a release, and there never will 
   be. Sure, there's a first commit that I do, but that has absolutely 
   zero relevance.

   Learn this. Until you do, you'll be confused, and you'll show your 
   confusion by saying "I want a 2.6.n+1-rc0". You'll _also_ show your 
   confusion by things like "I was bisecting a bug that happened between 
   2.6.30 and 2.6.31, and suddenly git was asking me to test a kernel that 
   said it was version 2.6.29-rc1 - so I stopped bisecting because git was 
   confused".

Who was confused? Was it git, or was it the person who thought that the 
Makefile version could be consistent in a non-linear world?

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.

			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/