Re: (Short?) merge window reminder
On Tue, 2011-05-24 at 11:07 -0400, jonsm...@gmail.com wrote: On Tue, May 24, 2011 at 10:43 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: Can we drop most of MCA, EISA and ISA bus if we are going to have a big version change ? A driver spring clean is much overdue and it's all in git in case someone wishes to sneak out at midnight and bring some crawly horror back from the dead. 2.8 could mark the beginning of the great cleanup --- work out the details of what needs to be cleaned and set a goal --- remove old buses/driver, switch to device tree, graphics, 32/64 merges, etc 3.0 would mark its completion Here it go my opinion, Many people ask for beginning of 2.7 kernel series which will end on 2.8, by old numeration. Kernel 2.8 will mainly a major clean up, of support of the very old hardware, like math co-processor at only exist in 386 and before Pentium. If some one want put Linux on this very old hardware should use kernel 2.2. However a new numeration of kernel is independent of this, and I agree with new numeration of kernel on drop a number. Last but not least, I would like to see marked a hiper stable kernel , which will be used by Debian guys. Debian guys tend to stop in a kernel which is not the best one, so let we choose for them what is the stable of stables . Best regards, -- Sérgio M. B. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tuesday 2011-05-24 17:46, Ralf Baechle wrote: On Tue, May 24, 2011 at 03:43:48PM +0100, Alan Cox wrote: Can we drop most of MCA, EISA and ISA bus if we are going to have a big version change ? A driver spring clean is much overdue and it's all in git in case someone wishes to sneak out at midnight and bring some crawly horror back from the dead. Dunno about MCA but I doubt we can kill all of (E)ISA. i8253, i8259 and a few others still refuse hard to die. Is it worth to setup a system to track success / failure reports for drivers and ditch drivers once there are no success reports for a driver for too long? It may not be a good idea - people tend not report success much more rarely than failure. (On that matter, I wonder if there are 5.25 USB floppy drives ...) If there were, they would appear as Mass Storage devices (at least the 3.5 USB floppy gadgets do), and as such, don't depend on ISA or the classic floppy driver at all. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. How about stardates? That'd make a release made now 64860.8 I really should sleep more... -- Lisa Milne l...@ltmnet.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 07:17:21PM -0400, Ted Ts'o wrote: So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. If we change from 2.6.X to 3.X, then if we don't change anything else, then successive stable release will cause the LINUX_VERSION_CODE to be incremented. This isn't necessary bad, but it would be a different from what we have now. It will require another bunch of changes to scripts that try to make sense out of kernel Linux version numbers. It's a minor issue and we might be better off doing something else than version number magic. Not last a new major version number raises expectations - whatever those might be. Ralf ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, May 24, 2011 at 03:43:48PM +0100, Alan Cox wrote: Can we drop most of MCA, EISA and ISA bus if we are going to have a big version change ? A driver spring clean is much overdue and it's all in git in case someone wishes to sneak out at midnight and bring some crawly horror back from the dead. Dunno about MCA but I doubt we can kill all of (E)ISA. i8253, i8259 and a few others still refuse hard to die. Is it worth to setup a system to track success / failure reports for drivers and ditch drivers once there are no success reports for a driver for too long? It may not be a good idea - people tend not report success much more rarely than failure. (On that matter, I wonder if there are 5.25 USB floppy drives ...) Ralf ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On 23.05.2011 13:33, Linus Torvalds wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. What about strictly 3 part versions? Just add a .0. 3.0.0 - Release Kernel 3.0 3.0.1 - Stable 1 3.0.2 - Stable 2 3.1.0 - Release Kernel 3.1 3.1.1 - Stable 1 ... Biggest problem is likely version phobics that get pimples when they see trailing zeros. ;-) Bis denn -- Real Programmers consider what you see is what you get to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a you asked for it, you got it text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, 24 May 2011, Matthias Schniedermeyer wrote: On 23.05.2011 13:33, Linus Torvalds wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. What about strictly 3 part versions? Just add a .0. 3.0.0 - Release Kernel 3.0 3.0.1 - Stable 1 3.0.2 - Stable 2 3.1.0 - Release Kernel 3.1 3.1.1 - Stable 1 ... Biggest problem is likely version phobics that get pimples when they see trailing zeros. ;-) since there are always issues discovered with a new kernel is released (which is why the -stable kernels exist), being wary of .0 kernels is not neccessarily a bad thing. I still think a date based approach would be the best. since people are worried about not knowing when a final release will happen, base the date on when the merge window opened or closed (always known at the time of the first -rc kernel) in the thread on lwn, people pointed out that the latest 2.6.32 kernel would still be a 2009.12.X which doesn't reflect the fact that it was released this month. My suggestion for that is to make the X be the number of months (or years.months if you don't like large month values) between the merge window and the release of the -stable release. This would lead to a small problem when there are multiple -stable releases in a month, but since that doesn't last very long I don't see a real problem with just incramenting the month into the future in those cases. David Lang ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
Linus Torvalds wrote: PS. The voices in my head also tell me that the numbers are getting too big. I may just call the thing 2.8.0. And I almost guarantee that this PS is going to result in more discussion than the rest, but when the voices tell me to do things, I listen. Correct :) I would still prefer the version number change to something like 2011.0 - already proposed at http://kerneltrap.org/Linux/Kernel_Release_Numbering_Redux I don't think that it is reasonable to say that it is bad because third party scripts would break - they would break anyway (I would bet that many of them don't expect to see 3.x anyway). And changing now to 3.0 and then incrementing the second one everytime for 10 years will also lead to something like 3.56.7. I would also say that defining the release number using the time of the merge window start/end is easy understandable. 2.6.40 would be the third development cycle this year aka v2011.2 or v2011.2.0 when the patchlevel should always be included. -- Emil Langrock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
Hi, 2011/5/24 Lisa Milne l...@ltmnet.com: So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. How about stardates? This is a wonderful idea! :) That'd make a release made now 64860.8 I really should sleep more... -- Lisa Milne l...@ltmnet.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Slawa! Zimny Lech z Wawelu ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tuesday 2011-05-24 20:48, eschvoca wrote: On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote: It's not about features. It hasn't been about features for forever. Using the date also clearly communicates it is not about features. On the contrary: Whenever a 2.6.x release was set out the door, there was at least one new feature in the cycle. Given the endless manpower that seems to trail Linux, that seems unlikely to change in the near term. On It is not about features - it is not /just/ about features - it is also about fixes, which are equally important, and they also warrant a version bump of some sort on their own. Pointing out the obvious, the stable serieses. Fleeing to date-based version numbering seems like an excuse for making way for releases without any change whatsoever. (IOW, if there were features/fixes, a non-date based scheme of incremental numbers could indicate them already.) Me, a nobody end user, would prefer a version number that corresponded to the date. Something like: %y.%m.stable patch %Y.%m.stable patch Except that LINUX_KERNEL_VERSION has only 8 bits for each, so 2011 is out of range, which would need to kept in mind. And a 2-digit spec.. nah that does not feel very 100-year proof. (Just look at struct tm.tm_year for the mess 2-digits made technically.) Then users would know the significance of the number and when a vendor says they support Linux 11.09 the user will immediately know if they are up to date. An added issue with that would be that numbers would not increase in same-sized steps anymore and leave gaps. (There would probably be no 11.06 between 11.05 aka 2.6.39 and 11.07-or-so aka 2.6.40) My 2円. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Monday 23 May 2011, 22:33:48 Linus Torvalds wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. But no, it wouldn't be for 42. Despite THHGTTG, I think 40 is a fairly nice round number. There's also the timing issue - since we no longer do version numbers based on features, but based on time, just saying we're about to start the third decade works as well as any other excuse. But hey, do you really want to release a Linux 3.0 kernel without serious layered filesystem functionality? Shame on you, Pete PS.: Sorry for being such a pest in this regard, but filesystem layering is one of the most important missing bits to excel out of the box in * live distros * diskless computing * flash based systems Even the linux based commercial PBX solution (mobydick), I bought, ships with it. PPS.: Bad timing, I know, but I'm glad, that Al is back to life again.. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, 24 May 2011, Andy Lutomirski wrote: Also, when someone in my lab installs insert ancient enterprise distro here on a box that's running software I wrote that needs to support modern high-speed peripherals, then I can say What? You seriously expect this stuff to work on Linux 2007? Let's install a slightly less stable distro from at least 2010. This sounds a lot less nerdy than What? You seriously expect this stuff to work on Linux 2.6.27? Let's install a slightly less stable distro that uses at least 2.6.36. I hate to jump into this excellent example of bike-shedding discussion, but anyway ... Your example doesn't really reflect reality. It's common for older enterprise distributions to gradually incorporate a lot of backported code (and most importantly new hardware support code/drivers) while not upgrading the kernel major version. So yes, you will in reality get 2.6.16 kernel (at least according to uname) with libata with newer service packs of SLES 10, for example (and you could find many of those across distributions). -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tuesday 24 May 2011 23:05:30 Jan Engelhardt wrote:
On Tuesday 2011-05-24 20:48, eschvoca wrote:
On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote:
It's not about features. It hasn't been about features for forever.
Using the date also clearly communicates it is not about features.
On the contrary: Whenever a 2.6.x release was set out the door, there
was at least one new feature in the cycle. Given the endless manpower
that seems to trail Linux, that seems unlikely to change in the near
term.
On It is not about features - it is not /just/ about features - it
is also about fixes, which are equally important, and they also
warrant a version bump of some sort on their own. Pointing out the
obvious, the stable serieses.
You are mixing up features based versioning and identifier for versions. Linux
has no feature based concept for most parts of their version number (only the
patch part clearly states: fixes, fixes, fixes). We only need something that
is easily readable and maybe has no extreme weird meaning that leads to false
conclusions. And yes, that is what eschvoca meant and not something like
linux is stagnating.
Fleeing to date-based version numbering seems like an excuse
for making way for releases without any change whatsoever.
(IOW, if there were features/fixes, a non-date based scheme of
incremental numbers could indicate them already.)
Yes, that is usally the case... release the same source tarball again and
again. I always had that feeling when looking at those wine, ubuntu, gentoo,
ms, texlive, iasl, hugin, u-boot, ... developers. They are doing nothing the
whole day and the marketing department does everything.
Me, a nobody end user, would prefer a version number that corresponded
to the date. Something like:
%y.%m.stable patch
%Y.%m.stable patch
Except that LINUX_KERNEL_VERSION has only 8 bits for each,
so 2011 is out of range, which would need to kept in mind.
And a 2-digit spec.. nah that does not feel very 100-year
proof. (Just look at struct tm.tm_year for the mess 2-digits
made technically.)
What is LINUX_KERNEL_VERSION? I only know LINUX_VERSION_CODE and
KERNEL_VERSION
And the calculation behind it is following:
(((a) 16) + ((b) 8) + (c))
So for KERNEL_VERSION(2,6,40) we would get 0x20628 and for
KERNEL_VERSION(2011,2,0) we would get 0x07DB0200. Of course our
grandgrandgrand...grand children would die in agony in the year 65536.
And maybe (probably the module version check guys will kill me) could use a
compressed version of that without hurding the comparison function in out of
kernel modules. KERNEL_VERSION_Y(a,b) would be defined as
#define KERNEL_VERSION_Y(a,b) ({typeof (a) _a = a; \
typeof (b) _b = b; \
KERNEL_VERSION(_a 8, _a 0xff, _b); })
This would bring us to the year 16777216 before everybody gets punched in his
private parts by the versioning scheme. It is also possible to get more out of
32 bits when we can assume that Linus or his grandgrand...grand children will
never do more than 128 releases a year.
But yes, I aggree not to use 2 digit numbers for years unless we want to
start the y2k+100 problem here.
Then users would know the significance of the number and when a vendor
says they support Linux 11.09 the user will immediately know if they
are up to date.
An added issue with that would be that numbers would not increase in
same-sized steps anymore and leave gaps. (There would probably be no
11.06 between 11.05 aka 2.6.39 and 11.07-or-so aka 2.6.40)
Ok, this is really a good example why we should not use the month for
releases, but an ever increasing number until the first number is also
increased which resets the second number to 0.
Kind regards,
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tuesday 24 May 2011, Linus Torvalds 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. 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.. I like that. While I don't really care if you call it 2.7, 2.8 or 3.0 (or 4.0 even, if you want to keep continuity following .38 and .39), the current 2.5/2.6 numbering cycle is almost 10 years old and has obviously lost all significance. The only reason I can see that would make it worthwhile waiting for is if the enterprise and embedded people were to decide on a common longterm kernel and call that e.g. 2.7.x or 2.8.x while you continue with 2.9.x or 3.0.x or 3.x. My impression is however that the next longterm release is still one or two years away, so probably not worth waiting for and hard to estimate in advance. 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. We still have stable and unstable releases, except that you call the unstable ones -rcX and they are all nice and short, unlike the infamous 2.1.xxx series ;-) IMHO simply changing the names from 2.6.40-rcX to 2.7.X and from 2.6.40.X to 2.6.8.X etc would be the most straightforward change if you want to save the 3.0 release for a special moment. Enough bike shedding from my side, please just make a decision. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, 23 May 2011, Linus Torvalds wrote: PS. The voices in my head also tell me that the numbers are getting too big. I may just call the thing 2.8.0. And I almost guarantee that this PS is going to result in more discussion than the rest, but when the voices tell me to do things, I listen. So the voices tell you to avoid .42 ? Thanks, tglx ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, 2011-05-23 at 12:22 -0700, Greg KH wrote: On Mon, May 23, 2011 at 12:13:29PM -0700, Linus Torvalds wrote: PS. The voices in my head also tell me that the numbers are getting too big. I may just call the thing 2.8.0. And I almost guarantee that this PS is going to result in more discussion than the rest, but when the voices tell me to do things, I listen. If you do this, I will buy you a bottle of whatever whiskey you want that I can get my hands on in Tokyo next week. I can recommend Hanyu Ace of Spades ... I can even arrange to be on hand just to make sure it's as good as it should be ... James ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, May 24, 2011 at 00:33, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. But no, it wouldn't be for 42. Despite THHGTTG, I think 40 is a fairly nice round number. There's also the timing issue - since we no longer do version numbers based on features, but based on time, just saying we're about to start the third decade works as well as any other excuse. But we'll see. Maybe, 2011.x, or 11.x, x increasing for every merge window started this year? This would better reflect the steady nature of the releases, but would certainly break a lot of scripts. ;) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 01:21:26PM -0700, Randy Dunlap wrote: They tell him to avoid the question to which 42 is the answer. What 2.6 Linux kernel version was the last before 3.0? -- Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On 5/23/11, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) I think, the best time for this, after reorganize the ARM arch folder / tree. So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. But no, it wouldn't be for 42. Despite THHGTTG, I think 40 is a fairly nice round number. There's also the timing issue - since we no longer do version numbers based on features, but based on time, just saying we're about to start the third decade works as well as any other excuse. But we'll see. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. If we change from 2.6.X to 3.X, then if we don't change anything else, then successive stable release will cause the LINUX_VERSION_CODE to be incremented. This isn't necessary bad, but it would be a different from what we have now. - Ted ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 03:21:21PM -0700, Greg KH wrote: On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. I like that, it would make things much easier for me to keep track of stuff. As long as 3.14 turns into a long-term support kernel and gets up to 159 ... In all serious, I'm very supportive of this move. I'm heartily sick of people claiming we have version 2.6 support when they really mean they haven't updated since version 2.6.9. Yeah, congratulations, you're seven years out of date. -- Matthew Wilcox Intel Open Source Technology Centre Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tuesday 2011-05-24 01:33, Linus Torvalds 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.
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.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
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.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
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.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
2011/5/24 Jan Engelhardt jeng...@medozas.de:
On Tuesday 2011-05-24 01:33, Linus Torvalds 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.
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.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
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.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
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.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
What then about BKL removal? Nice place to celebrate with version jump
and heaving some beers.
-Jacek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tuesday 2011-05-24 14:30, Jacek Luczak wrote:
2011/5/24 Jan Engelhardt jeng...@medozas.de:
On Tuesday 2011-05-24 01:33, Linus Torvalds 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.
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.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
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.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
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.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
What then about BKL removal? Nice place to celebrate with version jump
and heaving some beers.
The BKL going away was not a change that would require new
userspace programs.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
2011/5/24 Jan Engelhardt jeng...@medozas.de:
On Tuesday 2011-05-24 14:30, Jacek Luczak wrote:
2011/5/24 Jan Engelhardt jeng...@medozas.de:
On Tuesday 2011-05-24 01:33, Linus Torvalds 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.
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.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
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.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
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.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
What then about BKL removal? Nice place to celebrate with version jump
and heaving some beers.
The BKL going away was not a change that would require new
userspace programs.
True but as you I guess - kind off - notice there's no such event that
would launch fireworks and we get features smoothly. By that then we
should celebrate killing old nightmares aka BKL. It's more like - lets
not find the reason but include one just to feel better. At the end
the simplified version convention is the best reason to do this cut
off. I even plan to send a truck full of chickens to Linus if this
will convince him :) Then, while describing new kernel deployment, I
won't need to pronounce the cool sounding - ,,Mika so I've now
installed two(dot)six(dot)thirty-five(dot)forty-one(dash)one
version.''
Cheers,
-Jacek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
If we change from 2.6.X to 3.X, then if we don't change anything else, then successive stable release will cause the LINUX_VERSION_CODE to be incremented. This isn't necessary bad, but it would be a different from what we have now. I think I prefer 3 digits. Otherwise we will have to pass 3.0, 3.1 and 3.11 all of which numbers still give older sysadmins flashbacks and will have them waking screaming in the middle of the night. Also saves breaking all the tools and assumptions people have been used to for some many years Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
Can we drop most of MCA, EISA and ISA bus if we are going to have a big version change ? A driver spring clean is much overdue and it's all in git in case someone wishes to sneak out at midnight and bring some crawly horror back from the dead. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, May 24, 2011 at 10:43 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: Can we drop most of MCA, EISA and ISA bus if we are going to have a big version change ? A driver spring clean is much overdue and it's all in git in case someone wishes to sneak out at midnight and bring some crawly horror back from the dead. 2.8 could mark the beginning of the great cleanup --- work out the details of what needs to be cleaned and set a goal --- remove old buses/driver, switch to device tree, graphics, 32/64 merges, etc 3.0 would mark its completion -- Jon Smirl jonsm...@gmail.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On 05/24/2011 08:07 AM, jonsm...@gmail.com wrote: On Tue, May 24, 2011 at 10:43 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: Can we drop most of MCA, EISA and ISA bus if we are going to have a big version change ? A driver spring clean is much overdue and it's all in git in case someone wishes to sneak out at midnight and bring some crawly horror back from the dead. 2.8 could mark the beginning of the great cleanup --- work out the details of what needs to be cleaned and set a goal --- remove old buses/driver, switch to device tree, graphics, 32/64 merges, etc 3.0 would mark its completion I think this whole discussion misses the essence of the new development model, which is that we no longer do these kinds of feature-based major milestones. If we want to to deprecate lots of drivers (which I personally would advocate against -- I have built systems specifically to run a real floppy drive since the Linux floppy driver is amazingly flexible and can read/write a lot of formats that nothing else can, including USB floppies) then we should do that in the normal course of action, incrementally, and listed in feature-removal-schedule.txt, not all at once due to some arbitrary milestone. We have found it works better this way. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, May 24, 2011 at 10:36 AM, H. Peter Anvin h...@zytor.com wrote: I think this whole discussion misses the essence of the new development model, which is that we no longer do these kinds of feature-based major milestones. Indeed. It's not about features. It hasn't been about features for forever. So a renumbering would be purely about dropping the numbers to something smaller and more easily recognized. The ABI wouldn't change. The API wouldn't change. There wouldn't be any big because we finally did xyz. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On 05/23/2011 04:33 PM, Linus Torvalds wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnarmi...@elte.hu wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. But no, it wouldn't be for 42. Despite THHGTTG, I think 40 is a fairly nice round number. There's also the timing issue - since we no longer do version numbers based on features, but based on time, just saying we're about to start the third decade works as well as any other excuse. I don't think year-based versions (like 2011.0 for the first 2011 release, or maybe 2011.5 for May 2011) are pretty, but I'll make an argument for them anyway: it makes it easier to figure out when hardware ought to be supported. So if I buy a 2014-model laptop and the coffee-making button doesn't work, and my favorite distro is running the 2013 kernel, then I know I shouldn't expect to it to work. (Graphics drivers are probably a more realistic example.) Also, when someone in my lab installs insert ancient enterprise distro here on a box that's running software I wrote that needs to support modern high-speed peripherals, then I can say What? You seriously expect this stuff to work on Linux 2007? Let's install a slightly less stable distro from at least 2010. This sounds a lot less nerdy than What? You seriously expect this stuff to work on Linux 2.6.27? Let's install a slightly less stable distro that uses at least 2.6.36. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, 24 May 2011 14:30:59 +0200, Jacek Luczak said:
2011/5/24 Jan Engelhardt jeng...@medozas.de:
On Tuesday 2011-05-24 01:33, Linus Torvalds 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.
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.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
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.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
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.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
What then about BKL removal? Nice place to celebrate with version jump
and heaving some beers.
Well, if we're looking at ELF-sized ABI changes, how about 3.0 be the
release where we re-sync the syscall numbers on all the archs? ;)
pgp21lBpIoZeR.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 12:13:29PM -0700, Linus Torvalds wrote:
PS. The voices in my head also tell me that the numbers are getting
too big. I may just call the thing 2.8.0. And I almost guarantee that
this PS is going to result in more discussion than the rest, but when
the voices tell me to do things, I listen.
If you do this, I will buy you a bottle of whatever whiskey you want
that I can get my hands on in Tokyo next week.
{crosses fingers}
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, 23 May 2011 21:25:25 +0200 (CEST) Thomas Gleixner wrote: On Mon, 23 May 2011, Linus Torvalds wrote: PS. The voices in my head also tell me that the numbers are getting too big. I may just call the thing 2.8.0. And I almost guarantee that this PS is going to result in more discussion than the rest, but when the voices tell me to do things, I listen. So the voices tell you to avoid .42 ? They tell him to avoid the question to which 42 is the answer. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. But no, it wouldn't be for 42. Despite THHGTTG, I think 40 is a fairly nice round number. There's also the timing issue - since we no longer do version numbers based on features, but based on time, just saying we're about to start the third decade works as well as any other excuse. But we'll see. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
* Linus Torvalds torva...@linux-foundation.org wrote: PS. The voices in my head also tell me that the numbers are getting too big. I may just call the thing 2.8.0. And I almost guarantee that this PS is going to result in more discussion than the rest, but when the voices tell me to do things, I listen. I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) Ingo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. I like that, it would make things much easier for me to keep track of stuff. But no, it wouldn't be for 42. Despite THHGTTG, I think 40 is a fairly nice round number. There's also the timing issue - since we no longer do version numbers based on features, but based on time, just saying we're about to start the third decade works as well as any other excuse. That sounds reasonable as well. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 4:33 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. Could we set a goal of having 3.0 be the first release with a totally cleaned up ARM arch? That would give everyone a good target to work towards. -- Jon Smirl jonsm...@gmail.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, 23 May 2011 19:17:21 -0400 Ted Ts'o wrote: On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. If we change from 2.6.X to 3.X, then if we don't change anything else, then successive stable release will cause the LINUX_VERSION_CODE to be incremented. This isn't necessary bad, but it would be a different from what we have now. It's just another little thing to break several scripts... --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
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. 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. 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. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
Hi Linus, On 05/23/2011 04:33 PM, Linus Torvalds wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. A few months ago, I briefly considered suggesting that the demise of the BKL would be a suitable milestone for the numbering shakeup. But I am a mere mortal lurker, and I remember past flame-fests this topic spawned. So I chickened out. As a small-scale linux evangelist, I would sure like to skip the explanation of the version numbers. Phil ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
* Linus Torvalds torva...@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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
* Linus Torvalds torva...@linux-foundation.org wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu wrote: I really hope there's also a voice that tells you to wait until .42 before cutting 3.0.0! :-) So I'm toying with 3.0 (and in that case, it really would be 3.0, not 3.0.0 - the stable team would get the third digit rather than the fourth one. But no, it wouldn't be for 42. Despite THHGTTG, I think 40 is a fairly nice round number. Also, in all fairness, we should probably display a certain amount of humility: while Linux has certainly reached milestones such as world domination (as far as large and small computers are concerned), so calling it 3.0 is a fair deal, we probably have to wait for version 42.0 before we can consider the Linux kernel to be the ultimate answer to life, universe and everything. Thanks, Ingo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
