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 16:44:49 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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

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

> 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.

I understand non-linear history, but still i think that it might make 
sense to make it more apparent that the tree people pull from you after 
.31 got released is a lot closer to what .32 is going to be than to .31. 
(which the name implies)

I.e. i think it's a fact that right now our release version is highly 
deceptive during the merge window. Two days into the merge window and we 
have more commits added than we add from .31-rc7 to .31-rc9 total. A 
week into the merge window we have .31 + 6000 commits merged and still 
call it v2.6.31, to the casual looker.

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. 
Personally i really want people to try our git trees, but them also be 
fully aware of the risks involved.

One option would be to make LOCALVERSION_AUTO compulsory.

Or to add a tweak to the naming, something like:

 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

Would make it clear what's going on, even in the simplified world of 
limited-size version numbers.

Or, IMHO it would also be a valid naming model to do this small tweak to 
the above naming scheme:

 v2.6.31
 v2.6.32-rc0
 v2.6.32-rc0+
 v2.6.32-rc1
 v2.6.32-rc1+
 ..
 v2.6.32-rc9
 v2.6.32-rc9+
 v2.6.32

... for the sole purpose of warning people that anything they pull after 
v2.6.31 got released is (wildly!) not vanilla v2.6.31 anymore. Not more, 
not less.

Am i confused? :-)

	Ingo
--
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/