From: Ingo Molnar <mingo@elte.hu> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com>, Ted Ts'o <tytso@mit.edu>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-arch@vger.kernel.org, DRI <dri-devel@lists.freedesktop.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, linux-mm <linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org>, Greg KH <gregkh@suse.de> Subject: Re: (Short?) merge window reminder Date: Tue, 24 May 2011 04:01:35 +0200 [thread overview] Message-ID: <20110524020135.GA19249@elte.hu> (raw) In-Reply-To: <BANLkTikGfVSAMY2a2yiXaNpvBVvF8YdMEA@mail.gmail.com> * Linus Torvalds <torvalds@linux-foundation.org> wrote: > Another advantage of switching numbering models (ie 3.0 instead of > 2.8.x) would be that it would also make the "odd numbers are also > numbers" transition much more natural. Yeah, it sounds really good to get rid of the (meanwhile) meaningless "2.6." prefix from our version code and iterate it in a more meaningful way. I suspect the stable team and distros will enjoy the more meaningful third digit as well: it will raise the perceived importance of stabilization and packaging work. Btw., we should probably remove the fourth (patch) level, otherwise distros might feel tempted to fill it in with their own patch-stack version number, which would result in confusing "3.3.1.5" meaning different things on different distros - while 3.3.1-5.rpm style of distro kernel package naming denotes the distro patch level more clearly. I don't think the odd/even history will linger too long: in practice we'll iterate through 3.1, 3.2, 3.3 and 3.4 rather quickly, in the first year, so any residual notion of stable/unstable will be gone within a few iterations. > Because of our historical even/odd model, I wouldn't do a 2.7.x - > there's just too much history of 2.1, 2.3, 2.5 being development > trees. But if I do 3.0, then I'd be chucking that whole thing out the > window, and the next release would be 3.1, 3.2, etc.. > > And then in another few years (probably before getting close to 3.40, > so I'm not going to make a big deal of 3 = "third decade"), I'd just > do 4.0 etc. Perhaps we could do 4.0 once the last bit of -rt hits upstream? /me ducks > Because all our releases are supposed to be stable releases these > days, and if we get rid of one level of numbering, I feel perfectly > fine with getting rid of the even/odd history too. They are very stable releases as far as i'm concerned - i can pretty confidently run and use -rc2 and better kernels on my boxes these days and could do so for the past few years. Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: "H. Peter Anvin" <hpa@zytor.com>, Ted Ts'o <tytso@mit.edu>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-arch@vger.kernel.org, DRI <dri-devel@lists.freedesktop.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, linux-mm <linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org>, Greg KH <gregkh@suse.de> Subject: Re: (Short?) merge window reminder Date: Tue, 24 May 2011 04:01:35 +0200 [thread overview] Message-ID: <20110524020135.GA19249@elte.hu> (raw) Message-ID: <20110524020135.5PbLmfK_eoX6VghAW2TifRh2-jsjZq9ZGZMrlxgLoak@z> (raw) In-Reply-To: <BANLkTikGfVSAMY2a2yiXaNpvBVvF8YdMEA@mail.gmail.com> * Linus Torvalds <torvalds@linux-foundation.org> wrote: > Another advantage of switching numbering models (ie 3.0 instead of > 2.8.x) would be that it would also make the "odd numbers are also > numbers" transition much more natural. Yeah, it sounds really good to get rid of the (meanwhile) meaningless "2.6." prefix from our version code and iterate it in a more meaningful way. I suspect the stable team and distros will enjoy the more meaningful third digit as well: it will raise the perceived importance of stabilization and packaging work. Btw., we should probably remove the fourth (patch) level, otherwise distros might feel tempted to fill it in with their own patch-stack version number, which would result in confusing "3.3.1.5" meaning different things on different distros - while 3.3.1-5.rpm style of distro kernel package naming denotes the distro patch level more clearly. I don't think the odd/even history will linger too long: in practice we'll iterate through 3.1, 3.2, 3.3 and 3.4 rather quickly, in the first year, so any residual notion of stable/unstable will be gone within a few iterations. > Because of our historical even/odd model, I wouldn't do a 2.7.x - > there's just too much history of 2.1, 2.3, 2.5 being development > trees. But if I do 3.0, then I'd be chucking that whole thing out the > window, and the next release would be 3.1, 3.2, etc.. > > And then in another few years (probably before getting close to 3.40, > so I'm not going to make a big deal of 3 = "third decade"), I'd just > do 4.0 etc. Perhaps we could do 4.0 once the last bit of -rt hits upstream? /me ducks > Because all our releases are supposed to be stable releases these > days, and if we get rid of one level of numbering, I feel perfectly > fine with getting rid of the even/odd history too. They are very stable releases as far as i'm concerned - i can pretty confidently run and use -rc2 and better kernels on my boxes these days and could do so for the past few years. Thanks, Ingo
next prev parent reply other threads:[~2011-05-24 2:01 UTC|newest] Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-05-23 19:13 (Short?) merge window reminder Linus Torvalds 2011-05-23 19:13 ` Linus Torvalds 2011-05-23 19:20 ` Ingo Molnar 2011-05-23 19:20 ` Ingo Molnar 2011-05-23 20:33 ` Linus Torvalds 2011-05-23 20:33 ` Linus Torvalds 2011-05-23 20:52 ` Alexey Zaytsev 2011-05-25 14:12 ` Boaz Harrosh 2011-05-25 22:21 ` Tony Luck 2011-05-25 22:21 ` Tony Luck 2011-05-26 16:38 ` Boaz Harrosh 2011-05-23 21:59 ` Oliver Pinter 2011-05-23 22:21 ` Greg KH 2011-05-23 23:40 ` Matthew Wilcox 2011-05-23 23:40 ` Matthew Wilcox 2011-05-23 23:10 ` jonsmirl 2011-05-23 23:17 ` Ted Ts'o 2011-05-23 23:17 ` Ted Ts'o 2011-05-23 23:21 ` Randy Dunlap 2011-05-23 23:23 ` H. Peter Anvin 2011-05-23 23:33 ` Linus Torvalds 2011-05-23 23:33 ` Linus Torvalds 2011-05-24 2:01 ` Ingo Molnar [this message] 2011-05-24 2:01 ` Ingo Molnar 2011-05-24 7:55 ` Arnd Bergmann 2011-05-24 7:55 ` Arnd Bergmann 2011-05-24 12:15 ` Jan Engelhardt 2011-05-24 12:15 ` Jan Engelhardt 2011-05-24 12:30 ` Jacek Luczak 2011-05-24 13:02 ` Jan Engelhardt 2011-05-24 13:18 ` Jacek Luczak 2011-05-24 14:43 ` Alan Cox 2011-05-24 14:43 ` Alan Cox 2011-05-24 15:07 ` jonsmirl 2011-05-24 15:07 ` jonsmirl 2011-05-24 17:36 ` H. Peter Anvin 2011-05-24 17:36 ` H. Peter Anvin 2011-05-24 17:41 ` Linus Torvalds 2011-05-24 18:48 ` eschvoca 2011-05-24 21:05 ` Jan Engelhardt 2011-05-25 9:12 ` Emil Langrock 2011-05-26 16:13 ` Sérgio Basto 2011-05-26 16:13 ` Sérgio Basto 2011-05-24 15:46 ` Ralf Baechle 2011-05-24 17:29 ` Jan Engelhardt 2011-05-25 1:13 ` Valdis.Kletnieks 2011-05-23 23:23 ` H. Peter Anvin 2011-05-24 14:41 ` Alan Cox 2011-05-24 14:41 ` Alan Cox 2011-05-24 14:48 ` Ralf Baechle 2011-05-24 14:48 ` Ralf Baechle 2011-05-23 23:53 ` Phil Turmel 2011-05-23 23:53 ` Phil Turmel 2011-05-24 2:11 ` Ingo Molnar 2011-05-24 2:11 ` Ingo Molnar 2011-05-24 18:06 ` Lisa Milne 2011-05-24 18:06 ` Lisa Milne 2011-05-24 20:59 ` Zimny Lech 2011-05-24 20:59 ` Zimny Lech 2011-05-25 15:03 ` Martin Nybo Andersen 2011-05-25 15:03 ` Martin Nybo Andersen 2011-05-24 18:34 ` Matthias Schniedermeyer 2011-05-24 18:34 ` Matthias Schniedermeyer 2011-05-24 18:55 ` david 2011-05-24 18:55 ` david 2011-05-24 21:25 ` Andy Lutomirski 2011-05-24 21:25 ` Andy Lutomirski 2011-05-25 12:52 ` Jiri Kosina 2011-05-25 12:52 ` Jiri Kosina 2011-05-24 23:00 ` Hans-Peter Jansen 2011-05-24 23:00 ` Hans-Peter Jansen 2011-05-23 19:22 ` Greg KH 2011-05-23 19:22 ` Greg KH 2011-05-23 20:04 ` James Bottomley 2011-05-23 20:04 ` James Bottomley 2011-05-23 19:25 ` Thomas Gleixner 2011-05-23 20:21 ` Randy Dunlap 2011-05-23 20:21 ` Randy Dunlap 2011-05-23 21:02 ` Steven Rostedt 2011-05-23 21:02 ` Steven Rostedt 2011-05-24 19:06 ` Emil Langrock
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20110524020135.GA19249@elte.hu \ --to=mingo@elte.hu \ --cc=akpm@linux-foundation.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=gregkh@suse.de \ --cc=hpa@zytor.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=torvalds@linux-foundation.org \ --cc=tytso@mit.edu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).