Linux 3.0-rc1
Linus Torvalds
begin (or at least re-start).
I decided to just bite the bullet, and call the next version 3.0. It
will get released close enough to the 20-year mark, which is excuse
enough for me, although honestly, the real reason is just that I can
no longe rcomfortably count as high as 40.
The whole renumbering was discussed at last years Kernel Summit, and
there was a plan to take it up this year too. But let's face it -
what's the point of being in charge if you can't pick the bike shed
color without holding a referendum on it? So I'm just going all
alpha-male, and just renumbering it. You'll like it.
Now, my alpha-maleness sadly does not actually extend to all the
scripts and Makefile rules, so the kernel is fighting back, and is
calling itself 3.0.0-rc1. We'll have the usual 6-7 weeks to wrestle it
into submission, and get scripts etc cleaned up, and the final release
should be just "3.0". The -stable team can use the third number for
their versioning.
So what are the big changes?
NOTHING. Absolutely nothing. Sure, we have the usual two thirds driver
changes, and a lot of random fixes, but the point is that 3.0 is
*just* about renumbering, we are very much *not* doing a KDE-4 or a
Gnome-3 here. No breakage, no special scary new features, nothing at
all like that. We've been doing time-based releases for many years
now, this is in no way about features. If you want an excuse for the
renumbering, you really should look at the time-based one ("20 years")
instead.
So no ABI changes, no API changes, no magical new features - just
steady plodding progress. In addition to the driver changes (and the
bulk really is driver updates), we've had some nice VFS cleanups,
various VM fixes, some nice initial ARM consolidation (yay!) and in
general this is supposed to be a fairly normal release cycle. The
merge window was a few days shorter than usual, but if that ends up
meaning a smaller release and a nice stable 3.0 release, that is all
good. There's absolutely no reason to aim for the traditional ".0"
problems that so many projects have.
In fact, I think that in addition to the shorter merge window, I'm
also considering make this one of my "Linus is being a difficult
^&^hole" releases, where I really want to be pretty strict about what
I pull during the stabilization window. Part of that is that I'm going
to be traveling next week with a slow atom laptop, so you had better
convince me I *really* want to pull from you, because that thing
really is not the most impressive piece of hardware ever built. It
does the "git" workflow quite well, but let's just say that compiling
the kernel is not quite the user experience I've gotten used to.
So be nice to me, and send me only really important fixes. And let's
make sure we really make the next release not just an all new shiny
number, but a good kernel too.
Ok?
Go forth and test,
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linus Torvalds
tar-balls and patches are now in a new directory:
/pub/linux/kernel/v3.0
(under "testing/", since that's what we do with -rc releases).
However, I did *not* rename the git tree, because that would just be a
huge inconvenience to git users, so it's still in the same old place
and yes, that means that my git tree is still called "linux-2.6.git"
on kernel.org. But it has the v3.0-rc1 tag in it.
I'll probably add a symlink or something, if people really hate being
reminded about our long history with the "2.6" numbering. But that
won't be until closer to the real release, methinks.
Rafael J. Wysocki
Well, actually there is one. ;-) The shutdown/suspend/resume callbacks have
been removed from struct sysdev_class and struct sysdev_driver.
Not that this is important to anyone except for the 10 people or so who care,
but still. :-)
Thanks for the numbering change,
Rafael
Greg KH
> Yay! Let the bikeshed painting discussions about version numbering
> begin (or at least re-start).
>
> I decided to just bite the bullet, and call the next version 3.0. It
> will get released close enough to the 20-year mark, which is excuse
> enough for me, although honestly, the real reason is just that I can
> no longe rcomfortably count as high as 40.
>
> The whole renumbering was discussed at last years Kernel Summit, and
> there was a plan to take it up this year too. But let's face it -
> what's the point of being in charge if you can't pick the bike shed
> color without holding a referendum on it? So I'm just going all
> alpha-male, and just renumbering it. You'll like it.
>
> Now, my alpha-maleness sadly does not actually extend to all the
> scripts and Makefile rules, so the kernel is fighting back, and is
> calling itself 3.0.0-rc1. We'll have the usual 6-7 weeks to wrestle it
> into submission, and get scripts etc cleaned up, and the final release
> should be just "3.0". The -stable team can use the third number for
> their versioning.
Wonderful, I personally really appreciate this, as I think the numbering
sequence of the kernel affects me the most at times with the stable
work.
What kind of whiskey should I get for you in Tokyo. Any
recommendations?
greg "happy as a clam" k-h
CaT
> scripts and Makefile rules, so the kernel is fighting back, and is
> calling itself 3.0.0-rc1. We'll have the usual 6-7 weeks to wrestle it
> into submission, and get scripts etc cleaned up, and the final release
> should be just "3.0". The -stable team can use the third number for
> their versioning.
Why not just keep the sublevel 0 for your release and let stable team
modify it for their release. That way you release 3.0.0, 3.1.0, 3.2.0
and stable do 3.0.1, 3.1.3, 3.2.1, etc. Less script breakage that way.
--
"A search of his car uncovered pornography, a homemade sex aid, women's
stockings and a Jack Russell terrier."
- http://www.dailytelegraph.com.au/news/wacky/indeed/story-e6frev20-1111118083480
Américo Wang
<torv...@linux-foundation.org> wrote:
> Oh, and as some people already noticed, the numbering means that the
> tar-balls and patches are now in a new directory:
>
> /pub/linux/kernel/v3.0
>
> (under "testing/", since that's what we do with -rc releases).
> However, I did *not* rename the git tree, because that would just be a
> huge inconvenience to git users, so it's still in the same old place
> and yes, that means that my git tree is still called "linux-2.6.git"
> on kernel.org. But it has the v3.0-rc1 tag in it.
>
> I'll probably add a symlink or something, if people really hate being
> reminded about our long history with the "2.6" numbering. But that
> won't be until closer to the real release, methinks.
>
You are not alone, Linus, David also has net-2.6 and net-next-2.6. :)
Thanks for the release!
(/me is looking forward to seeing you in Japan...)
Arkadiusz Miskiewicz
> On Sun, May 29, 2011 at 06:30:32PM -0700, Linus Torvalds wrote:
> > Now, my alpha-maleness sadly does not actually extend to all the
> > scripts and Makefile rules, so the kernel is fighting back, and is
> > calling itself 3.0.0-rc1. We'll have the usual 6-7 weeks to wrestle it
> > into submission, and get scripts etc cleaned up, and the final release
> > should be just "3.0". The -stable team can use the third number for
> > their versioning.
>
> Why not just keep the sublevel 0 for your release and let stable team
> modify it for their release. That way you release 3.0.0, 3.1.0, 3.2.0
> and stable do 3.0.1, 3.1.3, 3.2.1, etc. Less script breakage that way.
I guess some distros will do that way on their own.
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
Boaz Harrosh
> Oh, and as some people already noticed, the numbering means that the
> tar-balls and patches are now in a new directory:
>
> /pub/linux/kernel/v3.0
>
> (under "testing/", since that's what we do with -rc releases).
> However, I did *not* rename the git tree, because that would just be a
> huge inconvenience to git users, so it's still in the same old place
> and yes, that means that my git tree is still called "linux-2.6.git"
> on kernel.org. But it has the v3.0-rc1 tag in it.
>
> I'll probably add a symlink or something, if people really hate being
> reminded about our long history with the "2.6" numbering. But that
> won't be until closer to the real release, methinks.
>
> Linus
If you are leaving the three digits system, then I still think my system
was the best. Perhaps you have not seen it?
D.Y.N
D = the decade from 1991. So it always changes on 20?1
Y = The year in the decade. Since it all started in 1991 then
1 <= Y <= 10. To also denote that we never have a zero version
N = The release number of that year. Also start from 1.
1 <= Y <= 5
Y and D gets advanced not in the first release of the year around
march, but on the last release of the Year the one close to Christmas
So this Kernel is 3.1.3, then 3.1.4 3.2.1 ... 3.10.4, 4.1.1 and so
on. Always beautiful numbers. single increment, the one that knows
can easily calculate the date it was released.
Also alternatively the middle number (Y) can jump every two years
so 1 <= Y <= 5 and 1 <= N <= 9 to make it more even
If you read this and ignored it for been boring then I apologize.
I thought that your original idea was to drop a digit, but if it is
here to stay, then perhaps this is a good way to fight it back.
Cheers
Boaz
Tarkan Erimer
My suggestion is "Jack Daniel's Silver Select", if Linus desires of
course :-)
Ingo Molnar
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git perf-urgent-for-linus
I kept this one really simple, because AFAICS this is the first ever
3.0 pull request sent to you on lkml, and i do not want to go down in
history as the idiot who sent the first broken tree to you in this
new and exciting 3.0 kernel age! ;-)
Thanks,
Ingo
------------------>
Steven Rostedt (1):
x86: Put back -pg to tsc.o and add no GCOV to vread_tsc_64.o
arch/x86/kernel/Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index f5abe3a..90b06d4 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -8,6 +8,7 @@ CPPFLAGS_vmlinux.lds += -U$(UTS_MACHINE)
ifdef CONFIG_FUNCTION_TRACER
# Do not profile debug and lowlevel utilities
+CFLAGS_REMOVE_tsc.o = -pg
CFLAGS_REMOVE_rtc.o = -pg
CFLAGS_REMOVE_paravirt-spinlocks.o = -pg
CFLAGS_REMOVE_pvclock.o = -pg
@@ -28,6 +29,7 @@ CFLAGS_paravirt.o := $(nostackp)
GCOV_PROFILE_vsyscall_64.o := n
GCOV_PROFILE_hpet.o := n
GCOV_PROFILE_tsc.o := n
+GCOV_PROFILE_vread_tsc_64.o := n
GCOV_PROFILE_paravirt.o := n
# vread_tsc_64 is hot and should be fully optimized:
Sedat Dilek
[QUOTE]
h, and as some people already noticed, the numbering means that the
tar-balls and patches are now in a new directory:
/pub/linux/kernel/v3.0
(under "testing/", since that's what we do with -rc releases).
However, I did *not* rename the git tree, because that would just be a
huge inconvenience to git users, so it's still in the same old place
and yes, that means that my git tree is still called "linux-2.6.git"
on kernel.org. But it has the v3.0-rc1 tag in it.
I'll probably add a symlink or something, if people really hate being
reminded about our long history with the "2.6" numbering. But that
won't be until closer to the real release, methinks.
Linus
[/QUOTE]
First of all, congrats to Linux v3.0-rc1!
As you have found by yourself this new numbering forces a bit of
rethinking some of (y)our (daily) workflows.
( The new location of Linux v3.0-rc1 tarball was my 1st "problem" when
converting my kernel-buildsystem. )
[A] REPOSITORY NAMES
BUT...
...your GIT tree is still called "linux-2.6" :-).
Lots of other GIT repsoitories still use a prefix "linux-2.6-", like
linux-2.6-tip, linux-2.6-rcu, linux-2.6-acpi, or look at net-2.6 or
drm-2.6.
NOW...
...it would be a good point to rename all repos to a more general/common name.
Especially, the "linux-2.6-" can go to /dev/nirvana.
[1] lists all trees merged into linux-next and can be used as an overview.
Here some examples with proposals for change:
EXAMPLE #1: Repos containing "linux-2.6-" prefix (IMHO even "linux-"
as prefix can be dropped)
1. linux-2.6-tip -> tip
2. linux-2.6-rcu -> rcu
3. linux-2.6-acpi -> acpi
EXAMPLE #2: Repos containing "-2.6" as suffix
1. net-2.6 -> net
2. drm-2.6 -> drm
3. wireless-2.6 -> wireless
4. sound-2.6 -> sound
[ Gold medal to Ted for his ext4 GIT tree :-). ]
EXAMPLE #3: WTF trees not fitting #1 or #2
In general: Use the directory-name where your drivers are stored, see
also MAINTAINERS file.
EXAMPLE #4: Repos using a separate GIT repo with -next suffix (for linux-next)
1. net-next-2.6 -> net-next
2. wireless-next-2.6 -> wireless-next
I know people won't like the idea on 1st look and hate me for no real
benefit/new features, but...
...PLEASE...
...don't start renaming to "3.0", in a decade we have the same problem
:-( and thus do it right from the beginning.
Thoughts?
[B] MY EXPERIENCES WITH v3.0-rc1
Here my 1st impressions:
I am mostly on linux-next and working with an adopted
kernel-buildsystem from Debian kernel team.
As a quick workaround, I changed package-name from "linux-2.6" to "linux-3.0".
This also led to a new folder linux-3.0 below $HOME/src.
A two digits major version number like 3.0(-rc1) is (currently) not
accepted, so the first line of debian/changelog looks like this:
linux-3.0 (3.0.0~rc1-1~next20110530.dileks1) UNRELEASED; urgency=low
So, I used for now 3.0.0~rc1 (Note: Debian uses ~rcX in changelog files).
IIRC some READMEs, copyright files below debian-dir etc. have to be
adopted, too.
But as this work is for my personal amusement, I build 1st and enjoy...
$ cat /proc/version
Linux version 3.0.0-rc1-next20110530.1-686-small (Debian
3.0.0~rc1-1~next20110530.dileks1) (sedat...@gmail.com) (gcc version
4.6.1 20110526 (prerelease) (Debian 4.6.0-10) ) #1 SMP Mon May 30
08:15:10 CEST 2011
- Sedat -
[1] http://git.us.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=Next/Trees
Miles Bader
> What kind of whiskey should I get for you in Tokyo. Any
> recommendations?
http://www.nikka.com/special/yoichi/lineup.html
If you're gonna be in Japan, I'd recommend Yoichi (a single-malt from
Nikka); it's one of the absolute best Japanese whiskies I've had.
[I've only had the 10- and 12-year old, both of which are very good, but
the 15-year old is supposed to be spectacular...]
-Miles
--
Scriptures, n. The sacred books of our holy religion, as distinguished from
the false and profane writings on which all other faiths are based.
Anca Emanuel
if yolu like. We want him to be on keyboarrd, and comment if something
is wromg.
Pekka Enberg
> Greg, please do NOT give strong alcohol to Linus, jutt give some beer
> if yolu like. We want him to be on keyboarrd, and comment if something
> is wromg.
Wouldn't it be best that Greg doesn't give strong alcohol to any Linux
maintainer until 3.0 is out just to be safe?
Wanlong Gao
> On Mon, May 30, 2011 at 1:09 PM, Anca Emanuel <anca.e...@gmail.com>
> wrote:
>> Greg, please do NOT give strong alcohol to Linus, jutt give some beer
>> if yolu like. We want him to be on keyboarrd, and comment if something
>> is wromg.
>
> Wouldn't it be best that Greg doesn't give strong alcohol to any Linux
> maintainer until 3.0 is out just to be safe?
Zhang, Shijie
Valdis.K...@vt.edu
> On Mon, May 30, 2011 at 1:09 PM, Anca Emanuel <anca.e...@gmail.com> wrote:
> > Greg, please do NOT give strong alcohol to Linus, jutt give some beer
> > if yolu like. We want him to be on keyboarrd, and comment if something
> > is wromg.
>
> Wouldn't it be best that Greg doesn't give strong alcohol to any Linux
> maintainer until 3.0 is out just to be safe?
It all depends on exactly *how much* alcohol you give them:
:)
Camille Moncelier
Linus Torvalds <torv...@linux-foundation.org> wrote:
>
> I decided to just bite the bullet, and call the next version 3.0. It
> will get released close enough to the 20-year mark, which is excuse
> enough for me, although honestly, the real reason is just that I can
> no longe rcomfortably count as high as 40.
So, this is a <odd>.x.y release right ? According to you the schedule
was:
> - 2.6.<odd>: still a stable kernel, but accept bigger changes leading
> up to it (timeframe: a month or two).
> - 2.<odd>.x: aim for big changes that may destabilize the kernel for
> several releases (timeframe: a year or two)
> - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and
> rewrote the kernel to be a microkernel using a special
> message-passing version of Visual Basic. (timeframe: "we expect that
> he will be released from the mental institution in a decade or
> two").
Then the big question is where's that microkernel stuff you promised ?
Does the travel you are planning next week has anything to do with the
mental institution ?
15Hz
Hash: SHA1
Hi!
So why do you want to call it 3.0? There is nothing new imho. Why do you
build another tree and name it sometime in the future 3.0 ?
reg.
Julien
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJN46SpAAoJEAKZu0xN1nlQOPQIAJyzxTuKOQpIvEqb16KN9EeP
egpiNoq26qpZ7Q8hT9XB4J3yzOnraFixLThpYNvZpCb5b4cFCAlaIlO++1MVtbJp
EsADSHcO272/6zmHaAQnN+g8VbboCY6BQWoi+erA850NBf7zOjcv/yUViM2xeXpB
gU3vG+Fy4s1ZLwEEbhnj+ngAdYbtuIRFR4UFb5iBMBC43/Rq7CawzdDsHwRFVsyE
sh325O3lLWQFlJBh0ohw+0bnWSBOCbJ7siTXlYMByedCedd322vO13Jiu2RCNJvs
s5f1PdwLrCCCH5JCSfJnFxfj6VUwjXWLFQwyu6FOTug0LYzzJjmo0mgb6A9ggdQ=
=wYMW
-----END PGP SIGNATURE-----
trapDoor
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi!
> So why do you want to call it 3.0? There is nothing new imho. Why do you
> build another tree and name it sometime in the future 3.0 ?
>
> reg.
> Julien
You may find the answer here:
http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=1383510;page=1;mh=-1;list=linux;sb=post_latest_reply;so=ASC
--
Thanks,
Tomasz
Steven Rostedt
> >
> > So no ABI changes, no API changes,
>
> Well, actually there is one. ;-) The shutdown/suspend/resume callbacks have
> been removed from struct sysdev_class and struct sysdev_driver.
And there's another one. The function tracer now allows different users
to pick different functions to trace! We don't actually have any true
users of that yet (perf will be the first, hopefully in 3.1), but it is
a new feature.
>
> Not that this is important to anyone except for the 10 people or so who care,
> but still. :-)
I think you have 9 more people that care about your change than mine ;)
-- Steve
Mariusz Kozlowski
[...]
> However, I did *not* rename the git tree, because that would just be a
> huge inconvenience to git users, so it's still in the same old place
> and yes, that means that my git tree is still called "linux-2.6.git"
> on kernel.org. But it has the v3.0-rc1 tag in it.
>
> I'll probably add a symlink or something, if people really hate being
> reminded about our long history with the "2.6" numbering. But that
> won't be until closer to the real release, methinks.
You could consider freezing linux-2.6.git repository and creating new
linux-3.git repository that would serve for a couple of years until
linux-4.git. At the same time development history could be dropped between
trees so that inital clones are lighter. Anyone interested in history
can download idx/pack from linux-2.6.git repo and attach it using gratf
point[1] anyway.
Pros:
- obvious naming scheme wrt repository contents
- smaller initial clone
- new clean tag namespace
Cons:
- broken bisection for some time
- impaired log/blame/whatchanged and friends
Cons can be fixed by attaching history when needed.
[1] https://git.wiki.kernel.org/index.php/GraftPoint
--
Mariusz Kozlowski
Mustapha Rabiu
>
> Yay! Let the bikeshed painting discussions about version numbering
> begin (or at least re-start).
>
> I decided to just bite the bullet, and call the next version 3.0. It
> will get released close enough to the 20-year mark, which is excuse
> enough for me, although honestly, the real reason is just that I can
> no longe rcomfortably count as high as 40.
>
Unsurprising, however, congratulations on yet another major release!
We applaud the fact that it'll be just as hideous as 2.6.x, without any
new or modified features. Might you explain why you didn't just
use 2.8.x ?
Also, given that multiple people have asked for a handful of things
to be merged into the kernel, re: security, I'm puzzled about how
you managed to develop this self-styled 'alpha-male' based versioning
scheme without addressing unsettling discrepancies such
as /proc/pid/auxv, /proc/pid/stack and /proc/pid/syscall based
info-leaks or slub cache merging, etc, all of which have been publicly
discussed over varying periods of time, (circa ~2008)
> The whole renumbering was discussed at last years Kernel Summit, and
> there was a plan to take it up this year too. But let's face it -
> what's the point of being in charge if you can't pick the bike shed
> color without holding a referendum on it? So I'm just going all
> alpha-male, and just renumbering it. You'll like it.
>
Again, without catering for pre-existing issues.
> Now, my alpha-maleness sadly does not actually extend to all the
> scripts and Makefile rules, so the kernel is fighting back, and is
> calling itself 3.0.0-rc1. We'll have the usual 6-7 weeks to wrestle it
> into submission, and get scripts etc cleaned up, and the final release
> should be just "3.0". The -stable team can use the third number for
> their versioning.
>
> So what are the big changes?
>
> NOTHING. Absolutely nothing.
Relatively disturbing. Again, why not use 2.8.x ?
> Sure, we have the usual two thirds driver
> changes, and a lot of random fixes, but the point is that 3.0 is
> *just* about renumbering, we are very much *not* doing a KDE-4 or a
> Gnome-3 here. No breakage, no special scary new features, nothing at
> all like that.
And none of the aforementioned issues.
> We've been doing time-based releases for many years
> now, this is in no way about features. If you want an excuse for the
> renumbering, you really should look at the time-based one ("20 years")
> instead.
>
> So no ABI changes, no API changes, no magical new features - just
> steady plodding progress. In addition to the driver changes (and the
> bulk really is driver updates), we've had some nice VFS cleanups,
> various VM fixes, some nice initial ARM consolidation (yay!) and in
> general this is supposed to be a fairly normal release cycle. The
> merge window was a few days shorter than usual, but if that ends up
> meaning a smaller release and a nice stable 3.0 release, that is all
> good. There's absolutely no reason to aim for the traditional ".0"
> problems that so many projects have.
>
> In fact, I think that in addition to the shorter merge window, I'm
> also considering make this one of my "Linus is being a difficult
> ^&^hole" releases, where I really want to be pretty strict about what
> I pull during the stabilization window.
Well, being an asshole is relatively different. This is a case of being stupid.
> Part of that is that I'm going to be traveling next week with a slow
> atom laptop, so you had better convince me I *really* want to
> pull from you, because that thing really is not the most impressive
> piece of hardware ever built. It does the "git" workflow quite well,
> but let's just say that compiling the kernel is not quite the user
> experience I've gotten used to.
>
> So be nice to me, and send me only really important fixes. And let's
> make sure we really make the next release not just an all new shiny
> number, but a good kernel too.
Being as most of the issues mentioned above have been prodded by several
people over the scope of over five years, to multiple maintainers, including
yourself, I'm not sure you'd pay any attention to amendments until some sort
of en-masse all-out holocaust arrives.
>
> Ok?
>
> Go forth and test,
> Linus
>
Yours, sincerely
Mustapha Rabiu.
Valdis.K...@vt.edu
> Linus Torvalds <torvalds <at> linux-foundation.org> writes:
>
> >
> > Yay! Let the bikeshed painting discussions about version numbering
> > begin (or at least re-start).
> >
> > I decided to just bite the bullet, and call the next version 3.0. It
> > will get released close enough to the 20-year mark, which is excuse
> > enough for me, although honestly, the real reason is just that I can
> > no longe rcomfortably count as high as 40.
> >
>
> Unsurprising, however, congratulations on yet another major release!
> We applaud the fact that it'll be just as hideous as 2.6.x, without any
> new or modified features. Might you explain why you didn't just
> use 2.8.x ?
>
> Also, given that multiple people have asked for a handful of things
> to be merged into the kernel, re: security, I'm puzzled about how
> you managed to develop this self-styled 'alpha-male' based versioning
> scheme without addressing unsettling discrepancies such
> as /proc/pid/auxv, /proc/pid/stack and /proc/pid/syscall based
> info-leaks or slub cache merging, etc, all of which have been publicly
> discussed over varying periods of time, (circa ~2008)
We can come back and revisit those issues after we get done fixing
*all* the software that made a blind assumption that the kernel
release number matches '2\.[46]\.[0-9]+' (said assumption being
broken at *both* ends by a 3.0 release.
I have to agree with Linus on this one - if we're ruling out ABI-breaking
changes, we want to make this kernel release as little different as
we can.
da...@lang.hm
> On Sun, May 29, 2011 at 06:47:57PM -0700, Linus Torvalds wrote:
>
> [...]
>
>> However, I did *not* rename the git tree, because that would just be a
>> huge inconvenience to git users, so it's still in the same old place
>> and yes, that means that my git tree is still called "linux-2.6.git"
>> on kernel.org. But it has the v3.0-rc1 tag in it.
>>
>> I'll probably add a symlink or something, if people really hate being
>> reminded about our long history with the "2.6" numbering. But that
>> won't be until closer to the real release, methinks.
>
> You could consider freezing linux-2.6.git repository and creating new
> linux-3.git repository that would serve for a couple of years until
> linux-4.git. At the same time development history could be dropped between
> trees so that inital clones are lighter. Anyone interested in history
> can download idx/pack from linux-2.6.git repo and attach it using gratf
> point[1] anyway.
>
> Pros:
> - obvious naming scheme wrt repository contents
> - smaller initial clone
> - new clean tag namespace
>
> Cons:
> - broken bisection for some time
> - impaired log/blame/whatchanged and friends
in addition won't there be problems merging in work done on the old tree?
(since there would be no common history)
everyone would need to re-clone their repository (and attaching history
wouldn't help this)
there are probably others.
frankly I don't see any real benifits from the Pros you list. the initial
clone is already rather small, it probably won't make that big a
difference to throw away several years of history.
David Lang
Mariusz Kozlowski
> >You could consider freezing linux-2.6.git repository and creating new
> >linux-3.git repository that would serve for a couple of years until
> >linux-4.git. At the same time development history could be dropped between
> >trees so that inital clones are lighter. Anyone interested in history
> >can download idx/pack from linux-2.6.git repo and attach it using gratf
> >point[1] anyway.
> >
> >Pros:
> >- obvious naming scheme wrt repository contents
> >- smaller initial clone
> >- new clean tag namespace
> >
> >Cons:
> >- broken bisection for some time
> >- impaired log/blame/whatchanged and friends
>
> in addition won't there be problems merging in work done on the old
> tree? (since there would be no common history)
Everyone would need to restart and probably reapply they changes on top
of new tree (because of lack of common history).
> everyone would need to re-clone their repository (and attaching
> history wouldn't help this)
>
> there are probably others.
>
> frankly I don't see any real benifits from the Pros you list. the
> initial clone is already rather small, it probably won't make that
> big a difference to throw away several years of history.
linux-2.6.git is all about lots of small changes so size isn't all that
big today but there are quite many objects. Using grafts might help
decreasing size of repository. I just mentioned it because it is a bit
of a revolution time anyway and otherwise current tree will grow for next
decade or so.
It's just an idea, I'm happy either way.
Thanks.
--
Mariusz Kozlowski
Benjamin Herrenschmidt
>
> Now, my alpha-maleness sadly does not actually extend to all the
> scripts and Makefile rules, so the kernel is fighting back, and is
> calling itself 3.0.0-rc1. We'll have the usual 6-7 weeks to wrestle it
> into submission, and get scripts etc cleaned up, and the final release
> should be just "3.0". The -stable team can use the third number for
> their versioning.
So a bit of bike shedding :-)
Why don't we just keep the 3 digits ? You release 3.x.0 and Greg
increments the last one ?
That means existing tools don't break, and number of digits doesn't
change all the time anymore, less likely to get wrong...
Cheers,
Ben.
Dave Airlie
<torv...@linux-foundation.org> wrote:
> Yay! Let the bikeshed painting discussions about version numbering
> begin (or at least re-start).
There's a rumour going around you broke module-init-tools.
So this is an ABI break? so can I break all my stuff as well ;-)
Dave.
Geert Uytterhoeven
NAK. I regularly look into full-history-linux as linux-2.6.git doesn't
have enough
history for me. Please don't make it worse.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Willy Tarreau
> Yay! Let the bikeshed painting discussions about version numbering
> begin (or at least re-start).
>
> will get released close enough to the 20-year mark, which is excuse
> enough for me, although honestly, the real reason is just that I can
> no longe rcomfortably count as high as 40.
>
> there was a plan to take it up this year too. But let's face it -
> what's the point of being in charge if you can't pick the bike shed
> color without holding a referendum on it? So I'm just going all
> alpha-male, and just renumbering it. You'll like it.
>
> scripts and Makefile rules, so the kernel is fighting back, and is
> calling itself 3.0.0-rc1. We'll have the usual 6-7 weeks to wrestle it
> into submission, and get scripts etc cleaned up, and the final release
> should be just "3.0". The -stable team can use the third number for
> their versioning.
Linus, two words : THANK YOU !
The 4-integer numbering was a real nightmare with kernel versions looking
like IP addresses. Now it will get back to something more common and much
more maintainable.
Thanks again for this huge step forwards !
Willy
Steven Rostedt
> So a bit of bike shedding :-)
Here's where I store my bike.
>
> Why don't we just keep the 3 digits ? You release 3.x.0 and Greg
> increments the last one ?
>
> That means existing tools don't break, and number of digits doesn't
> change all the time anymore, less likely to get wrong...
>
I think the problem with that is that it's still going to break scripts.
The changes in Greg's repo is a fork of Linus's kernel. Thus 3.0.1 will
not be an incremental step into 3.1.0. We wont be having patches that
take us from 3.0.1 to 3.1.0, so things like ketchup will break when it
tries to do such a thing without changing the way it currently works.
If we need to change ketchup (and other scripts) to handle this
difference, might as well do it correctly.
-- Steve
Sedat Dilek
"general/common" for his block-tree (see below):
linux-2.6-block -> linux-block
"description Linux 3.x block layer tree(s)"
Would be nice to see more maintainer following :-).
- Sedat -
[1] http://git.kernel.org/?p=linux/kernel/git/axboe/linux-block.git;a=summary
[2] http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=summary