linux-kernel - Re: [RFC] Kernel version numbering scheme change

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: <20081020202147.GA20788@kroah.com>
Date:	Mon, 20 Oct 2008 13:21:47 -0700
From:	Greg KH <greg@...ah.com>
To:	Alex Howells <alex@...emark.co.uk>
Cc:	Alexandre Oliva <oliva@....ic.unicamp.br>,
	"H. Peter Anvin" <hpa@...nel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Adrian Bunk <bunk@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] Kernel version numbering scheme change

On Mon, Oct 20, 2008 at 07:55:29PM +0100, Alex Howells wrote:
> Alexandre Oliva wrote:
>> Not that I care one way or the other.  It's just that I don't see how
>> your response bears any relationship with the point Greg made.  It's
>> just a distraction.  We're talking about how to label releases, not
>> about guessing the release date of a kernel months ahead.  One you
>> label it, it stays that way.
>
> Greg,
>
> I do agree with you that kernel numbering is becoming increasingly 
> cumbersome now the numbers are becoming larger, and a spreadsheet is 
> becoming a handy tool for tracking all this release information.
>
> I'm honestly not sold on any of the naming schemes proposed thusfar, but 
> since I can't come up with a magic solution, I'll shut up about that!
>
> What I'd love to see any changes integrate would be a simple way to spot 
> -stable releases in the version number (ie: 2.6.16, 2.6.27, those 
> maintained for a "long" time and hopefully by 2.6.16.50+ quite 'bug free') 
> versus the rest of releases sent out on a more regular basis.

What do you mean?  The .y marking of releases right now doesn't show you
this?

The "longevity" of a release series has no real correlation to it's "bug
free"ness of it in any strict sense of the word.  Just look at the
percentage of fixes in any normal release for "bugs" to get a concrete
feel for that (hint, it's in the thousands).

> I'll immediately concede this is probably of minimal benefit to 
> distribution maintainers who're actively following LKML and development in 
> general, but there is a big community of folks out there using vanilla 
> kernel.org sources for their own needs who, like me, probably find it 
> difficult/frustrating to pick a kernel version these days.

What is frustrating about it right now?  It is _strongly_ recommended
that if you are following the kernel.org tree, for you to rely on the
-stable releases.  It is best if you can upgrade to the latest branch of
the stable releases when they come out, moving to the latest major
release when possible, as you usually only have a month or so when they
start up before the previous branch's stable tree stops being
maintained.

Some times I think I need to put up a big .SVG drawing of all of the
releases, showing which ones are currently being maintained, and which
ones aren't just to make it easier.  I wonder if firefox could show it
properly, would that help out?

thanks,

greg k-h
--
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/