linux-kernel - Re: [kernel.org users] [kernel.org mirrors] XZ Migration discussion

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: <20100212231419.GB10266@1wt.eu>
Date:	Sat, 13 Feb 2010 00:14:19 +0100
From:	Willy Tarreau <w@....eu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"Sleddens, J.P.G." <j.p.g.sleddens@....nl>,
	"FTPAdmin Kernel.org" <ftpadmin@...nel.org>, mirrors@...nel.org,
	linux-kernel <linux-kernel@...r.kernel.org>, users@...nel.org
Subject: Re: [kernel.org users] [kernel.org mirrors] XZ Migration	discussion

On Fri, Feb 12, 2010 at 02:11:05PM -0800, H. Peter Anvin wrote:
> On 02/12/2010 12:31 PM, Sleddens, J.P.G. wrote:
> >>>> On 12-2-2010 at 20:03, "H. Peter Anvin" <hpa@...or.com> wrote:
> >> On 02/12/2010 06:01 AM, Jean Delvare wrote:
> >>> 3* Create a new subdirectory for every 2.6.x kernel, and move all the
> >>> related files there. This would shrink the main index drastically, and
> >>> each subdirectory would have a reasonable size (except maybe 2.6.16 and
> >>> 2.6.27.) Oddly enough this has been done for the files under testing/
> >>> already, so I am curious why we don't do it for the release files (and
> >>> the testing/incr/ files, while we're at it.)
> >>
> >> Well, part of the reason why is that we're functionally "stuck" on 2.6;
> >> a prefix which really has lost all meaning.
> >>
> >> It might open up the question if we shouldn't just do a Solaris and drop
> >> the leading 2 (so the next kernel would be 6.33) or call the kernel
> >> after that 3.0 instead of 2.6.34, and then 3.1 instead of 2.6.35.
> > 
> > I remember the whole LKML discussion about this a few years back:
> > http://lkml.org/lkml/2008/10/15/377 
> > 
> > The whole year.version   or year/month versioning Greg HK proposed
> > made a lot of sense to me.  It would also solve our problem with the 2.6
> > directory just growing and growing as the year versioning would make a
> > natural hierarchy which keeps going no matter what.
> 
> Note also that every time this conversation happens it starts to pull
> away in different directions, and as a result nothing happens.
> 
> I'm going to stick my foot in it and state the following: I think
> incremental numbers work well, and everyone are used to them.  It
> doesn't seem to be the major issue with the current scheme; the issue
> with the current scheme is that we have one or two levels too much.

Exactly. And for having worked with projects using dates, it's a hell
complicated to handle delayed releases... I'd like 3.0, 3.1, ... too,
and am using that scheme for my projects, which people easily understand
very well, as opposed to x.y.z.t.

But now I think that Linus has a "grep -v 3.0" filter on his inbox, I
never got a reply from him on the subject and I know I'm not the only
one :-(

Willy

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