[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <12c511ca1002122342x6a85459aic31f5c7e8f3786c1@mail.gmail.com>
Date: Fri, 12 Feb 2010 23:42:04 -0800
From: Tony Luck <tony.luck@...el.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Jean Delvare <khali@...ux-fr.org>, "J.H." <warthog9@...nel.org>,
"FTPAdmin Kernel.org" <ftpadmin@...nel.org>, users@...nel.org,
lasse.collin@...aani.org,
linux-kernel <linux-kernel@...r.kernel.org>, mirrors@...nel.org
Subject: Re: [kernel.org users] XZ Migration discussion
On Fri, Feb 12, 2010 at 11:03 AM, H. Peter Anvin <hpa@...or.com> wrote:
> 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.
This sounds like a good plan (and since we have so
far failed to come up with some new feature in Linux
that is so awesome that it warrants bumping the
version number to 3.0 ... we might as well manufacture
one, and "The HTML for the archive directory on
kernel.org has gotten too big" seems a pretty good
reason to me).
So the plan could be:
1) Declare 2.6.35 (or so) to be the last in the 2.6 series.
2) Define a better archive directory structure for the 3.x
releases (scripts will have to be changed anyway to
handle the 3.x change)
3) Keep all the .gz and .bz2 in the old 2.x hierarchy
4) Only have .xz in the new 3.x directories.
This should give time for people to update scripts
and for xz compression tools to become widely
available.
People on the bleeding edge versions are the most
likely ones to update their tools promptly. People
still using 2.x series kernels can keep using their
old tools forever.
-Tony
--
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/
Powered by blists - more mailing lists