LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re: [RFC] Kernel version numbering scheme change
@ 2008-10-20  6:05 Denys Fedoryshchenko
  0 siblings, 0 replies; 111+ messages in thread
From: Denys Fedoryshchenko @ 2008-10-20  6:05 UTC (permalink / raw)
  To: linux-kernel

Let me post my stupid idea :-) Dont hit me :-)

releasenum.branch.subreleasename(chars)+subreleasenumber(numbers).deepersubreleasename.....

1.vanilla.pre3
1.vanilla.rc1
1.vanilla.0 (stable release)
1.vanilla.fix1 (first stable patch)
2.mm.rc5
2.netdev.git2342424323423423

current versions, let's start from 2.6.27 looks like
2627.vanilla.0

next will be 2628


It is easy to parse, easy to find out what is a "base" release number, for 
patches and other trees

for mm's, for example, based on unstable kernels
mm.2.rc5.mm2
easy to understand, that it is mm branch, based on stable release 2, release 
candidate 5, mm patchset N2

Since Linus told there is no need in 2.6, probably there is no reason to keep 
even this numbers.

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-21 19:52                           ` Alex Howells
  2008-10-22  0:41                             ` Valdis.Kletnieks
@ 2008-10-22 18:11                             ` Stefan Richter
  1 sibling, 0 replies; 111+ messages in thread
From: Stefan Richter @ 2008-10-22 18:11 UTC (permalink / raw)
  To: Alex Howells
  Cc: Greg KH, Alexandre Oliva, H. Peter Anvin, Alan Cox, Adrian Bunk,
	Linus Torvalds, linux-kernel

Alex Howells wrote:
> So with regards to supported kernels, the following springs to mind:
> 
>    *  how long is kernel 2.6.xx supported?
>    *  is kernel 2.6.xx one of the "longer term" supported ones?
>    *  what are the requirements for a maintainer to push a
>       new release, a la 2.6.xx.yy? Is it based on time elapsed,
>       severity of any fixes included?
>    *  how do we define "support" in this context?
>       does it mean security problems discovered/fixed *after*
>       development focus has moved on to new stuff is backported?
>       does it mean [critical] bug fixes? regression fixes?

That's all quite simple to answer with a firm "depends".

  1. Remember, it's all volunteer work (by companies and individuals).

  2. Watch the release announcements and changelogs to learn about the
     lifetimes of -stable lines (they vary due to circumstances) and
     about what goes in into these lines.  There are also some bits in
     Documentation/stable_kernel_rules.txt.

Among else, it depends on volunteered manpower for patch verification
and even on sheer coincidence (somebody needs to be aware that an issue
is relevant to an active -stable line) whether a fix goes into -stable
or not.

Circumstances which lead to a -stable line remaining active for longer
than usual typically boil down to the motives of an individual developer
who picks up maintenance, like Adrian happened to do with 2.6.16.y and
plans to repeat with 2.6.27.y, or like Greg kept/ keeps 2.6.25.y active
alongside 2.6.26.y because it's directly useful to other work of his, AFAIU.

If you are interested in more structured release policies, you shouldn't
hesitate to have a look at vendor kernel lines.
-- 
Stefan Richter
-=====-==--- =-=- =-==-
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-22  8:58                               ` Alex Howells
@ 2008-10-22  9:11                                 ` Alan Cox
  0 siblings, 0 replies; 111+ messages in thread
From: Alan Cox @ 2008-10-22  9:11 UTC (permalink / raw)
  To: Alex Howells
  Cc: Valdis.Kletnieks, Greg KH, Alexandre Oliva, H. Peter Anvin,
	Adrian Bunk, Linus Torvalds, linux-kernel

On Wed, 22 Oct 2008 09:58:06 +0100
Alex Howells <alex@bytemark.co.uk> wrote:

> > And you win the trifecta - I don't think we've *ever* shipped a Linux kernel
> > that worked reliably under the proper "beat on the scheduler/VM corner case"
> > load/stress testing.  Again, the best you can hope for is "doesn't fall over

Upstream kernels can be a bit iffy especially on 32bit boxes with lots
of RAM. The enterprise vendor kernels have had months of tuning on high
load tests and behave far better than upstream. If you are running 32bit
and > 2GB of RAM I wouldn't even bother with upstream kernels to be
honest - pick one of the enterprise distributions or free repackagings
thereof. Better yet go 64bit ;)

At minimum with 2.6.x under high load you also need Arjan van de Ven's
patches to fix the ioprio mess - and god knows why those haven't been
accepted upstream given they make a huge difference to performance and
load handling.

http://lkml.org/lkml/2008/10/2/297

> > under non-pathological non-corner-case loads when sufficient resources are
> > available so the kernel has a fighting chance".  Doing 'make -j100' on a
> > single Core2 Duo is gonna be painful, no matter what.

Turn on strict overcommit and the box will degrade sanely and then if
need be start erroring things with out of memory before it goes kersplat.
That was a feature added a long time ago by Red Hat and then merged
upstream because serious business users of Linux need better guarantees
than the base kernel defaults.

If you have a non AMD processor without an IOMMU and are doing high
amounts of I/O make sure your I/O devices are 64bit capable - particular
watch SATA as most ATA hardware that isn't AHCI is 32bit constrained.

Alan

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-22  0:41                             ` Valdis.Kletnieks
  2008-10-22  4:15                               ` Grant Coady
@ 2008-10-22  8:58                               ` Alex Howells
  2008-10-22  9:11                                 ` Alan Cox
  1 sibling, 1 reply; 111+ messages in thread
From: Alex Howells @ 2008-10-22  8:58 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: Greg KH, Alexandre Oliva, H. Peter Anvin, Alan Cox, Adrian Bunk,
	Linus Torvalds, linux-kernel

Hey Valdis

>> Requirements for me to put a kernel on a given server would be:
> 
>>     *  supports the hardware
> The problem is that "supports" is often a fuzzy jello-like substance you
> try to nail to a tree.  You mention the R8169 and e1000 drivers - if they
> bring the device up, but have issues under corner cases, is that "supports"
> or not?

Oh agreed, this is all very "use case" specific.  I'm making all of the
following statements based on the specific hardware we use, and assuming
'stability' based on the kernel/hardware passing a number of tests.

>>     *  no security holes [in options I enable]
> Similarly for "no security holes".  At *BEST*, you'll get "no *known* *major*
> security holes", unless you feel like auditing the entire source tree.  There's
> a whole slew of bugs that we can't even agree if they *are* security bugs or
> just plain bugs - see Linus's rant on the subject a few months back.

Agreed. No *known* *major* security holes is fine here.

>>     *  works reliably, under load/stress.
> And you win the trifecta - I don't think we've *ever* shipped a Linux kernel
> that worked reliably under the proper "beat on the scheduler/VM corner case"
> load/stress testing.  Again, the best you can hope for is "doesn't fall over
> under non-pathological non-corner-case loads when sufficient resources are
> available so the kernel has a fighting chance".  Doing 'make -j100' on a
> single Core2 Duo is gonna be painful, no matter what.

Well the typical tests outlined above are:

    *  random size file creation/deletion, lots of files
    *  memory allocation, and freeing up again
    *  stressing the CPU a bit with one process, then
       forking 25-50 processes to (trivially) test scheduler
    *  testing network I/O by rapidly/concurrently fetching
       many small files via HTTP, and a few large ones.

The end goal is simply to get a server which doesn't crash under
"normal" operating conditions.  The bugs I referred to in
e1000/forcedeth and r8169 either stop it PXE booting (a requirement for
our environment!) or can *easily* be made to oops / stop working.

Alex


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-22  0:41                             ` Valdis.Kletnieks
@ 2008-10-22  4:15                               ` Grant Coady
  2008-10-22  8:58                               ` Alex Howells
  1 sibling, 0 replies; 111+ messages in thread
From: Grant Coady @ 2008-10-22  4:15 UTC (permalink / raw)
  To: Valdis.Kletnieks
  Cc: Alex Howells, Greg KH, Alexandre Oliva, H. Peter Anvin, Alan Cox,
	Adrian Bunk, Linus Torvalds, linux-kernel

On Tue, 21 Oct 2008 20:41:24 -0400, you wrote:

>On Tue, 21 Oct 2008 20:52:02 BST, Alex Howells said:
>> Requirements for me to put a kernel on a given server would be:
>
>>     *  supports the hardware
>The problem is that "supports" is often a fuzzy jello-like substance you
>try to nail to a tree.  You mention the R8169 and e1000 drivers - if they
>bring the device up, but have issues under corner cases, is that "supports"
>or not?
>
>>     *  no security holes [in options I enable]
>Similarly for "no security holes".  At *BEST*, you'll get "no *known* *major*
>security holes", unless you feel like auditing the entire source tree.  There's
>a whole slew of bugs that we can't even agree if they *are* security bugs or
>just plain bugs - see Linus's rant on the subject a few months back.
>
>>     *  works reliably, under load/stress.
>And you win the trifecta - I don't think we've *ever* shipped a Linux kernel
>that worked reliably under the proper "beat on the scheduler/VM corner case"
>load/stress testing.  Again, the best you can hope for is "doesn't fall over
>under non-pathological non-corner-case loads when sufficient resources are
>available so the kernel has a fighting chance".

>...  Doing 'make -j100' on a
>single Core2 Duo is gonna be painful, no matter what.

Not painful at all, make -j100 is four seconds faster than a make -j5 on 
a Core2Duo here with slamd64-12.1 (real: 3m21 vs 3m21).

Grant.
-- 
http://bugsplatter.id.au

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-21 19:52                           ` Alex Howells
@ 2008-10-22  0:41                             ` Valdis.Kletnieks
  2008-10-22  4:15                               ` Grant Coady
  2008-10-22  8:58                               ` Alex Howells
  2008-10-22 18:11                             ` Stefan Richter
  1 sibling, 2 replies; 111+ messages in thread
From: Valdis.Kletnieks @ 2008-10-22  0:41 UTC (permalink / raw)
  To: Alex Howells
  Cc: Greg KH, Alexandre Oliva, H. Peter Anvin, Alan Cox, Adrian Bunk,
	Linus Torvalds, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

On Tue, 21 Oct 2008 20:52:02 BST, Alex Howells said:
> Requirements for me to put a kernel on a given server would be:

>     *  supports the hardware
The problem is that "supports" is often a fuzzy jello-like substance you
try to nail to a tree.  You mention the R8169 and e1000 drivers - if they
bring the device up, but have issues under corner cases, is that "supports"
or not?

>     *  no security holes [in options I enable]
Similarly for "no security holes".  At *BEST*, you'll get "no *known* *major*
security holes", unless you feel like auditing the entire source tree.  There's
a whole slew of bugs that we can't even agree if they *are* security bugs or
just plain bugs - see Linus's rant on the subject a few months back.

>     *  works reliably, under load/stress.
And you win the trifecta - I don't think we've *ever* shipped a Linux kernel
that worked reliably under the proper "beat on the scheduler/VM corner case"
load/stress testing.  Again, the best you can hope for is "doesn't fall over
under non-pathological non-corner-case loads when sufficient resources are
available so the kernel has a fighting chance".  Doing 'make -j100' on a
single Core2 Duo is gonna be painful, no matter what.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-20 20:21                         ` Greg KH
@ 2008-10-21 19:52                           ` Alex Howells
  2008-10-22  0:41                             ` Valdis.Kletnieks
  2008-10-22 18:11                             ` Stefan Richter
  0 siblings, 2 replies; 111+ messages in thread
From: Alex Howells @ 2008-10-21 19:52 UTC (permalink / raw)
  To: Greg KH
  Cc: Alexandre Oliva, H. Peter Anvin, Alan Cox, Adrian Bunk,
	Linus Torvalds, linux-kernel

Greg KH wrote:
> What do you mean?  The .y marking of releases right now doesn't show you
> this?

Sorry, perhaps I wasn't clear with regards "bugs" vs. "regressions" as
someone else pointed out in a reply :)

> The "longevity" of a release series has no real correlation to it's "bug
> free"ness of it in any strict sense of the word.  Just look at the
> percentage of fixes in any normal release for "bugs" to get a concrete
> feel for that (hint, it's in the thousands).

Okay, sure.

> What is frustrating about it right now?  It is _strongly_ recommended
> that if you are following the kernel.org tree, for you to rely on the
> -stable releases.  It is best if you can upgrade to the latest branch of
> the stable releases when they come out, moving to the latest major
> release when possible, as you usually only have a month or so when they
> start up before the previous branch's stable tree stops being
> maintained.

That was what I was inviting people to solve, actually.

What I don't think is 100% clear right now is which kernels are still
actively maintained, and which are not.  When does a kernel become EoL?
This is different for things like 2.6.16.x and 2.6.27.x to others?
Perhaps this could be a part of the version numbering scheme?

I'm speaking only from personal experience here, but have had hideous
issues getting a "one kernel fits all" solution for boxes at work.
Requirements for me to put a kernel on a given server would be:

    *  supports the hardware
    *  no security holes [in options I enable]
    *  works reliably, under load/stress.

Now I wouldn't call myself an 'expert' by any means, so please forgive
me in advance if I'm wrong in any of the following...

A lot of the problems I've spotted have been traced (kind thanks to
Daniel Drake, Francois Romieu and others) to the network drivers,
particularly forcedeth/r8169 NICs actually but some e1000 stuff too.
Filing bugs and getting those issues fixed for everyone is important,
but sometimes the question remains "Why upgrade when 2.6.16.xx meets the
criteria above? Can we be sure 2.6.24.xx will be as stable?".

There is nothing stopping you setting aside a couple of boxes and
checking the latest -stable for testing purposes, for planning where you
*will* go when 2.6.16.xx stops being maintained, and filing any bugs you
spot along the way to try and contribute to this effort.

This mostly came about because we have a large-ish number of boxes
currently tracking 2.6.16.xx and that works *very* well for us.
Discovering that 2.6.16 would be maintained in such a way was tough
though as I'm only a fairly recent subscriber to LKML.

So with regards to supported kernels, the following springs to mind:

   *  how long is kernel 2.6.xx supported?
   *  is kernel 2.6.xx one of the "longer term" supported ones?
   *  what are the requirements for a maintainer to push a
      new release, a la 2.6.xx.yy? Is it based on time elapsed,
      severity of any fixes included?
   *  how do we define "support" in this context?
      does it mean security problems discovered/fixed *after*
      development focus has moved on to new stuff is backported?
      does it mean [critical] bug fixes? regression fixes?

> Some times I think I need to put up a big .SVG drawing of all of the
> releases, showing which ones are currently being maintained, and which
> ones aren't just to make it easier.  I wonder if firefox could show it
> properly, would that help out?

It would :)  Thanks for your response.

Alex

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-21 19:11                               ` Stefan Richter
@ 2008-10-21 19:16                                 ` Felipe Balbi
  0 siblings, 0 replies; 111+ messages in thread
From: Felipe Balbi @ 2008-10-21 19:16 UTC (permalink / raw)
  To: ext Stefan Richter
  Cc: felipe.balbi, Greg KH, Willy Tarreau, Alan Cox, Steven Noonan,
	Adrian Bunk, Linus Torvalds, linux-kernel

On Tue, Oct 21, 2008 at 09:11:52PM +0200, ext Stefan Richter wrote:
> Felipe Balbi wrote:
>> On Mon, Oct 20, 2008 at 02:06:48PM -0700, Greg KH wrote:
>>> On Mon, Oct 20, 2008 at 11:54:00PM +0300, Felipe Balbi wrote:
>>>> when we move to 2.7, we know it'll be the start
>>>> for the 2.8 kernel series.
>>> Um, did you not get the memo 3 years ago saying we are changing our
>>> development model and there will not be a 2.7 development series?
>>>
>>> Damm, I thought I had printed it out and placed it on everyone's chairs.
>>> Those pesky cleaners must have picked it up and recycled it, sorry about
>>> that...
>>>
>>>> Just like the migration from 2.4 to 2.5.
>>> Please don't bring up the dark ages again, many of us went through
>>> things back then that have taken a lot of counseling to be able to get
>>> over.
>>
>> sorry if i'm developing linux kernel for as long as you are. It's really
>> not my business how many hours of counseling you had to attend to get
>> over a version numbering change.
>
> The switch from 2.2/2.3/2.4/2.5 to 2.6.x was not a change of numbering 
> scheme, it was a change of the development model.  2.4 and 2.5 were two 
> parallel mainlines.  2.6.x is a single mainline, and there won't be two 
> mainlines again in any foreseeable future.

at least now you gave me the reasons and I got the point. Thanks for
clarifying.

-- 
balbi

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-20 22:24                             ` Felipe Balbi
@ 2008-10-21 19:11                               ` Stefan Richter
  2008-10-21 19:16                                 ` Felipe Balbi
  0 siblings, 1 reply; 111+ messages in thread
From: Stefan Richter @ 2008-10-21 19:11 UTC (permalink / raw)
  To: felipe.balbi
  Cc: Greg KH, Willy Tarreau, Alan Cox, Steven Noonan, Adrian Bunk,
	Linus Torvalds, linux-kernel

Felipe Balbi wrote:
> On Mon, Oct 20, 2008 at 02:06:48PM -0700, Greg KH wrote:
>> On Mon, Oct 20, 2008 at 11:54:00PM +0300, Felipe Balbi wrote:
>>> when we move to 2.7, we know it'll be the start
>>> for the 2.8 kernel series.
>> Um, did you not get the memo 3 years ago saying we are changing our
>> development model and there will not be a 2.7 development series?
>>
>> Damm, I thought I had printed it out and placed it on everyone's chairs.
>> Those pesky cleaners must have picked it up and recycled it, sorry about
>> that...
>>
>>> Just like the migration from 2.4 to 2.5.
>> Please don't bring up the dark ages again, many of us went through
>> things back then that have taken a lot of counseling to be able to get
>> over.
> 
> sorry if i'm developing linux kernel for as long as you are. It's really
> not my business how many hours of counseling you had to attend to get
> over a version numbering change.

The switch from 2.2/2.3/2.4/2.5 to 2.6.x was not a change of numbering 
scheme, it was a change of the development model.  2.4 and 2.5 were two 
parallel mainlines.  2.6.x is a single mainline, and there won't be two 
mainlines again in any foreseeable future.

> Maybe you still need a bit more, judging by your reply.

Or maybe not.  You obviously misread his post.
-- 
Stefan Richter
-=====-==--- =-=- =-=-=
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-20 18:55                       ` Alex Howells
  2008-10-20 20:21                         ` Greg KH
@ 2008-10-21 18:54                         ` Stefan Richter
  1 sibling, 0 replies; 111+ messages in thread
From: Stefan Richter @ 2008-10-21 18:54 UTC (permalink / raw)
  To: Alex Howells
  Cc: Alexandre Oliva, H. Peter Anvin, Greg KH, Alan Cox, Adrian Bunk,
	Linus Torvalds, linux-kernel

Alex Howells wrote:
> What I'd love to see any changes integrate would be a simple way to spot 
> -stable releases in the version number (ie: 2.6.16, 2.6.27, those 
> maintained for a "long" time and hopefully by 2.6.16.50+ quite 'bug 
> free') versus the rest of releases sent out on a more regular basis.

Side note:  Long-term maintained kernels like Adrian's 2.6.16.y or 
distro kernels of this sort -> are not 'quite bug free' <-.  They are 
only -> quite regression free <-.

If you want bug fixes, you generally want new kernels.  Only a fraction 
of the bug fixes in new kernels are backported to the long-term 
maintained stable kernels.  OTOH, also only a fraction of the 
regressions in new kernels is backported to them.
-- 
Stefan Richter
-=====-==--- =-=- =-=-=
http://arcgraph.de/sr/

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-20 21:06                           ` Greg KH
  2008-10-20 21:58                             ` Arnd Bergmann
@ 2008-10-20 22:24                             ` Felipe Balbi
  2008-10-21 19:11                               ` Stefan Richter
  1 sibling, 1 reply; 111+ messages in thread
From: Felipe Balbi @ 2008-10-20 22:24 UTC (permalink / raw)
  To: ext Greg KH
  Cc: Felipe Balbi, Willy Tarreau, Alan Cox, Steven Noonan,
	Adrian Bunk, Linus Torvalds, linux-kernel

On Mon, Oct 20, 2008 at 02:06:48PM -0700, Greg KH wrote:
> On Mon, Oct 20, 2008 at 11:54:00PM +0300, Felipe Balbi wrote:
> > On Mon, Oct 20, 2008 at 01:30:33PM -0700, Greg KH wrote:
> > > > IMHO, having a small number of small digits is the way to go. Using
> > > > 1 or 2 digits for the major and 1 for the minor is fine. After 3.9, you
> > > > go to version 4.0. Anyway, there are so many changes between versions
> > > > these days that any new versions could justify a major change (eg:
> > > > check the size of the 2.6.27 patch).
> > > > 
> > > > With versions from 1.1 to 9.9, you can go as high as 88 versions,
> > > > which is about 22 years of development at current pace. After that,
> > > > we can simply turn to 10.0 and not break anything.
> > > > 
> > > > It's also easier for users. Check how many non-kernel techies around you
> > > > know all 3 digits of the version they use. It's easier to remember 4.3
> > > > than it is to remember 2.6.27.
> > > 
> > > I agree that would be nicer, and easier for everyone.
> > 
> > It's true it would be easier for tracking down and remembering the
> > version number, but on the other hand, the good thing about this
> > version number system is that we now 2.6.xx is a rather stable and
> > complete kernel tree and when we move to 2.7, we know it'll be the start
> > for the 2.8 kernel series.
> 
> Um, did you not get the memo 3 years ago saying we are changing our
> development model and there will not be a 2.7 development series?
> 
> Damm, I thought I had printed it out and placed it on everyone's chairs.
> Those pesky cleaners must have picked it up and recycled it, sorry about
> that...
> 
> > Just like the migration from 2.4 to 2.5.
> 
> Please don't bring up the dark ages again, many of us went through
> things back then that have taken a lot of counseling to be able to get
> over.

sorry if i'm developing linux kernel for as long as you are. It's really
not my business how many hours of counseling you had to attend to get
over a version numbering change.

Maybe you still need a bit more, judging by your reply.

-- 
balbi

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-20 21:06                           ` Greg KH
@ 2008-10-20 21:58                             ` Arnd Bergmann
  2008-10-20 22:24                             ` Felipe Balbi
  1 sibling, 0 replies; 111+ messages in thread
From: Arnd Bergmann @ 2008-10-20 21:58 UTC (permalink / raw)
  To: Greg KH
  Cc: Felipe Balbi, Willy Tarreau, Alan Cox, Steven Noonan,
	Adrian Bunk, Linus Torvalds, linux-kernel

On Monday 20 October 2008, Greg KH wrote:
> Um, did you not get the memo 3 years ago saying we are changing our
> development model and there will not be a 2.7 development series?

Well, in theory we could resume the old numbering scheme again but
keep the current development model, in effect just inflating the
version numbers by one level:

2.6.28-rc1 -> 2.7.0
2.6.28-rc2 -> 2.7.1
2.6.28     -> 2.8.0 (perfect -- I've heard people informally call it
                     the two-eight release in the past instead of
                     two-six-twenty-eight)
2.6.28.1   -> 2.8.1
2.6.29-rc1 -> 2.9.0
2.6.29     -> 2.10.0 or 3.0.0 (depending on your taste)

This would be entirely consistent with how things have been since 1.0,
except that we have not had a 2.odd release in a long time.

	Arnd <><

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-20 20:54                         ` Felipe Balbi
@ 2008-10-20 21:06                           ` Greg KH
  2008-10-20 21:58                             ` Arnd Bergmann
  2008-10-20 22:24                             ` Felipe Balbi
  0 siblings, 2 replies; 111+ messages in thread
From: Greg KH @ 2008-10-20 21:06 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Willy Tarreau, Alan Cox, Steven Noonan, Adrian Bunk,
	Linus Torvalds, linux-kernel

On Mon, Oct 20, 2008 at 11:54:00PM +0300, Felipe Balbi wrote:
> On Mon, Oct 20, 2008 at 01:30:33PM -0700, Greg KH wrote:
> > > IMHO, having a small number of small digits is the way to go. Using
> > > 1 or 2 digits for the major and 1 for the minor is fine. After 3.9, you
> > > go to version 4.0. Anyway, there are so many changes between versions
> > > these days that any new versions could justify a major change (eg:
> > > check the size of the 2.6.27 patch).
> > > 
> > > With versions from 1.1 to 9.9, you can go as high as 88 versions,
> > > which is about 22 years of development at current pace. After that,
> > > we can simply turn to 10.0 and not break anything.
> > > 
> > > It's also easier for users. Check how many non-kernel techies around you
> > > know all 3 digits of the version they use. It's easier to remember 4.3
> > > than it is to remember 2.6.27.
> > 
> > I agree that would be nicer, and easier for everyone.
> 
> It's true it would be easier for tracking down and remembering the
> version number, but on the other hand, the good thing about this
> version number system is that we now 2.6.xx is a rather stable and
> complete kernel tree and when we move to 2.7, we know it'll be the start
> for the 2.8 kernel series.

Um, did you not get the memo 3 years ago saying we are changing our
development model and there will not be a 2.7 development series?

Damm, I thought I had printed it out and placed it on everyone's chairs.
Those pesky cleaners must have picked it up and recycled it, sorry about
that...

> Just like the migration from 2.4 to 2.5.

Please don't bring up the dark ages again, many of us went through
things back then that have taken a lot of counseling to be able to get
over.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-20 20:30                       ` Greg KH
@ 2008-10-20 20:54                         ` Felipe Balbi
  2008-10-20 21:06                           ` Greg KH
  0 siblings, 1 reply; 111+ messages in thread
From: Felipe Balbi @ 2008-10-20 20:54 UTC (permalink / raw)
  To: ext Greg KH
  Cc: Willy Tarreau, Alan Cox, Steven Noonan, Adrian Bunk,
	Linus Torvalds, linux-kernel

On Mon, Oct 20, 2008 at 01:30:33PM -0700, Greg KH wrote:
> > IMHO, having a small number of small digits is the way to go. Using
> > 1 or 2 digits for the major and 1 for the minor is fine. After 3.9, you
> > go to version 4.0. Anyway, there are so many changes between versions
> > these days that any new versions could justify a major change (eg:
> > check the size of the 2.6.27 patch).
> > 
> > With versions from 1.1 to 9.9, you can go as high as 88 versions,
> > which is about 22 years of development at current pace. After that,
> > we can simply turn to 10.0 and not break anything.
> > 
> > It's also easier for users. Check how many non-kernel techies around you
> > know all 3 digits of the version they use. It's easier to remember 4.3
> > than it is to remember 2.6.27.
> 
> I agree that would be nicer, and easier for everyone.

It's true it would be easier for tracking down and remembering the
version number, but on the other hand, the good thing about this
version number system is that we now 2.6.xx is a rather stable and
complete kernel tree and when we move to 2.7, we know it'll be the start
for the 2.8 kernel series.

Just like the migration from 2.4 to 2.5.

Also, changing now the version numbering would be troublesome as well.
Most of the users/developers who tracks linux-2.6.git are used to
have 3 levels of version number.

Still, it's nice to start thinking about it now since we're getting
closer to last sublevel of 2.4 series (i think it was 2.4.37 ??) and try
to find a new scheme for version numbering before thinking about 2.7 (or
3.0 ??) series.

-- 
balbi

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18  8:45                     ` Willy Tarreau
  2008-10-18 23:17                       ` Jiri Kosina
@ 2008-10-20 20:30                       ` Greg KH
  2008-10-20 20:54                         ` Felipe Balbi
  1 sibling, 1 reply; 111+ messages in thread
From: Greg KH @ 2008-10-20 20:30 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Alan Cox, Steven Noonan, Adrian Bunk, Linus Torvalds, linux-kernel

On Sat, Oct 18, 2008 at 10:45:05AM +0200, Willy Tarreau wrote:
> On Fri, Oct 17, 2008 at 02:44:09PM -0700, Greg KH wrote:
> > On Fri, Oct 17, 2008 at 08:47:23PM +0100, Alan Cox wrote:
> > > > And that's my point here, do we want to change the current numbering
> > > > scheme as people have expressed annoyances of the current one.
> > > 
> > > But any new scheme will be just as annoying to someone and it messes up
> > > existing documentation, understanding and risks breaking third party
> > > tools.
> > > 
> > > Is it really worth the hassle, plus we'll have to change again if we use
> > > date/times because once we are shipping Linux out to Alpha Centauri with
> > > colonists there will be serious problems trying to compute the effect of
> > > tau on release numbering ...
> > 
> > Sure, but by then, the 2.6.521 release will be out and we could fix it
> > up by finally going to 3.0 :)
> > 
> > Seriously, am I the only one that is getting annoyed by our version
> > numbers?  If so, I can live with it, but I got the feeling that I wasn't
> > alone here.
> 
> No you're not. I am too. Maybe we're both more annoyed than majority
> because we're mostly dealing with 4-numbers versions.
> 
> I remember having recently suggested someone to test 2.6.37, doing a
> confusion between 2.4.37 and 2.6.27. I have already tagged kernels
> with wrong versions, having to fix by hand afterwards. It's really
> cumbersome some times.

Yeah, I'm not the only one that has done that then :)

And yes, it is a pain to fix up.

> IMHO, having a small number of small digits is the way to go. Using
> 1 or 2 digits for the major and 1 for the minor is fine. After 3.9, you
> go to version 4.0. Anyway, there are so many changes between versions
> these days that any new versions could justify a major change (eg:
> check the size of the 2.6.27 patch).
> 
> With versions from 1.1 to 9.9, you can go as high as 88 versions,
> which is about 22 years of development at current pace. After that,
> we can simply turn to 10.0 and not break anything.
> 
> It's also easier for users. Check how many non-kernel techies around you
> know all 3 digits of the version they use. It's easier to remember 4.3
> than it is to remember 2.6.27.

I agree that would be nicer, and easier for everyone.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-20 18:55                       ` Alex Howells
@ 2008-10-20 20:21                         ` Greg KH
  2008-10-21 19:52                           ` Alex Howells
  2008-10-21 18:54                         ` Stefan Richter
  1 sibling, 1 reply; 111+ messages in thread
From: Greg KH @ 2008-10-20 20:21 UTC (permalink / raw)
  To: Alex Howells
  Cc: Alexandre Oliva, H. Peter Anvin, Alan Cox, Adrian Bunk,
	Linus Torvalds, linux-kernel

On Mon, Oct 20, 2008 at 07:55:29PM +0100, Alex Howells wrote:
> Alexandre Oliva wrote:
>> Not that I care one way or the other.  It's just that I don't see how
>> your response bears any relationship with the point Greg made.  It's
>> just a distraction.  We're talking about how to label releases, not
>> about guessing the release date of a kernel months ahead.  One you
>> label it, it stays that way.
>
> Greg,
>
> I do agree with you that kernel numbering is becoming increasingly 
> cumbersome now the numbers are becoming larger, and a spreadsheet is 
> becoming a handy tool for tracking all this release information.
>
> I'm honestly not sold on any of the naming schemes proposed thusfar, but 
> since I can't come up with a magic solution, I'll shut up about that!
>
> What I'd love to see any changes integrate would be a simple way to spot 
> -stable releases in the version number (ie: 2.6.16, 2.6.27, those 
> maintained for a "long" time and hopefully by 2.6.16.50+ quite 'bug free') 
> versus the rest of releases sent out on a more regular basis.

What do you mean?  The .y marking of releases right now doesn't show you
this?

The "longevity" of a release series has no real correlation to it's "bug
free"ness of it in any strict sense of the word.  Just look at the
percentage of fixes in any normal release for "bugs" to get a concrete
feel for that (hint, it's in the thousands).

> I'll immediately concede this is probably of minimal benefit to 
> distribution maintainers who're actively following LKML and development in 
> general, but there is a big community of folks out there using vanilla 
> kernel.org sources for their own needs who, like me, probably find it 
> difficult/frustrating to pick a kernel version these days.

What is frustrating about it right now?  It is _strongly_ recommended
that if you are following the kernel.org tree, for you to rely on the
-stable releases.  It is best if you can upgrade to the latest branch of
the stable releases when they come out, moving to the latest major
release when possible, as you usually only have a month or so when they
start up before the previous branch's stable tree stops being
maintained.

Some times I think I need to put up a big .SVG drawing of all of the
releases, showing which ones are currently being maintained, and which
ones aren't just to make it easier.  I wonder if firefox could show it
properly, would that help out?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-20  3:48                     ` Alexandre Oliva
  2008-10-20  5:29                       ` H. Peter Anvin
@ 2008-10-20 18:55                       ` Alex Howells
  2008-10-20 20:21                         ` Greg KH
  2008-10-21 18:54                         ` Stefan Richter
  1 sibling, 2 replies; 111+ messages in thread
From: Alex Howells @ 2008-10-20 18:55 UTC (permalink / raw)
  To: Alexandre Oliva
  Cc: H. Peter Anvin, Greg KH, Alan Cox, Adrian Bunk, Linus Torvalds,
	linux-kernel

Alexandre Oliva wrote:
> Not that I care one way or the other.  It's just that I don't see how
> your response bears any relationship with the point Greg made.  It's
> just a distraction.  We're talking about how to label releases, not
> about guessing the release date of a kernel months ahead.  One you
> label it, it stays that way.

Greg,

I do agree with you that kernel numbering is becoming increasingly 
cumbersome now the numbers are becoming larger, and a spreadsheet is 
becoming a handy tool for tracking all this release information.

I'm honestly not sold on any of the naming schemes proposed thusfar, but 
since I can't come up with a magic solution, I'll shut up about that!

What I'd love to see any changes integrate would be a simple way to spot 
-stable releases in the version number (ie: 2.6.16, 2.6.27, those 
maintained for a "long" time and hopefully by 2.6.16.50+ quite 'bug 
free') versus the rest of releases sent out on a more regular basis.

I'll immediately concede this is probably of minimal benefit to 
distribution maintainers who're actively following LKML and development 
in general, but there is a big community of folks out there using 
vanilla kernel.org sources for their own needs who, like me, probably 
find it difficult/frustrating to pick a kernel version these days.

Does anyone have a suggestion how that could be accomplished?

Alex

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-20  5:29                       ` H. Peter Anvin
@ 2008-10-20  7:13                         ` Alexandre Oliva
  0 siblings, 0 replies; 111+ messages in thread
From: Alexandre Oliva @ 2008-10-20  7:13 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: H. Peter Anvin, Greg KH, Alan Cox, Adrian Bunk, Linus Torvalds,
	linux-kernel

On Oct 20, 2008, "H. Peter Anvin" <hpa@zytor.com> wrote:

> Uhm, so what happens when a release starts with an -rc stage intended
> for 2008 release, and then comes out in 2009?

I see at least two possibilities:

- it stays 2008, as originally intended.

- it's labeled 2009 since the beginning of the release cycle

If it gets released in a year other than originally planned, it's no
more confusing that buying a 2009-series car in 2008, or Fiscal Years
vs Calendar Years.

Personally, I'd rather go with the second option than the first, if
nothing else because people seem to like better next year's stuff than
last year's stuff.  But it's not like it matters much.  The point
(AFAICT) is to give some rough guidance of the time-frame of the
release, not something like $(date +%s) of the beginning or end of the
release cycle.

Major might as well be defined as Year+/-1 - Constant, monotonically
increasing.  This should work and make sense as long as no release
cycle takes longer than say a year or two.

> Plus, of course, it makes it hard to talk about future releases.

Not that it makes a lot of sense to talk about future releases other
than the next two or so, but we could right now agree to use the
following replacement table.  Does your roadmap cover longer than
that?  Did I get the release year approximations wrong?

2.6.28 doesn't change
2.6.29 <-> 2009.1
2.6.30 <-> 2009.2
2.6.31 <-> 2009.3
2.6.32 <-> 2010.1
2.6.33 <-> 2010.2
2.6.34 <-> 2010.3
2.6.35 <-> 2010.4

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member       ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-20  3:48                     ` Alexandre Oliva
@ 2008-10-20  5:29                       ` H. Peter Anvin
  2008-10-20  7:13                         ` Alexandre Oliva
  2008-10-20 18:55                       ` Alex Howells
  1 sibling, 1 reply; 111+ messages in thread
From: H. Peter Anvin @ 2008-10-20  5:29 UTC (permalink / raw)
  To: Alexandre Oliva
  Cc: H. Peter Anvin, Greg KH, Alan Cox, Adrian Bunk, Linus Torvalds,
	linux-kernel

Alexandre Oliva wrote:
> 
>> We *really* don't want 2008.3-rc4 to be followed by 2009.1-rc5.
>> That is the kind of stuff that make script makers want to strangle
>> developers alive with their own intestines.
> 
> +1
> 
> Not that I care one way or the other.  It's just that I don't see how
> your response bears any relationship with the point Greg made.  It's
> just a distraction.  We're talking about how to label releases, not
> about guessing the release date of a kernel months ahead.  One you
> label it, it stays that way.
> 

Uhm, so what happens when a release starts with an -rc stage intended 
for 2008 release, and then comes out in 2009?  You either have to leave 
it at 2008, which would be confusing (I think this is what M$ did in at 
least one case), or you have to have an in-release-cycle change.

Plus, of course, it makes it hard to talk about future releases.

	-hpa

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16 15:35   ` Theodore Tso
                       ` (2 preceding siblings ...)
  2008-10-17  1:53     ` Dave Young
@ 2008-10-20  3:49     ` Daniel Phillips
  3 siblings, 0 replies; 111+ messages in thread
From: Daniel Phillips @ 2008-10-20  3:49 UTC (permalink / raw)
  To: Theodore Tso; +Cc: linux-kernel

On Thursday 16 October 2008 08:35, Theodore Tso wrote:
> Let's just leave things the way they are.

Or drop the useless fourth number and resume incrementing the minor
number if not the major.

Or just leave things the way they are, indeed.  I see Linus has
managed a prodigious silence on the troll, err, subject and with luck
it will stay that way.

Regards,

Daniel

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18  7:18                   ` H. Peter Anvin
@ 2008-10-20  3:48                     ` Alexandre Oliva
  2008-10-20  5:29                       ` H. Peter Anvin
  2008-10-20 18:55                       ` Alex Howells
  0 siblings, 2 replies; 111+ messages in thread
From: Alexandre Oliva @ 2008-10-20  3:48 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Greg KH, Alan Cox, Adrian Bunk, Linus Torvalds, linux-kernel

On Oct 18, 2008, "H. Peter Anvin" <hpa@kernel.org> wrote:

> Greg KH wrote:
>> What is the "problem" of predicting future releases?  What relies on the
>> actual number being "correct" some random time in the future?

> We already have the 2.6.28-rc series; and we are already talking about
> 2.6.29 features.

Just do like car manufacturers.  When it's 2008, you can already shop
around their 2009 models.  Linux could do the same.  We could right
now decide that 2.6.29 is going to be 2009.1 (or 9.1, or 2.9.1,
whatever), and then, even if it's still 2008 when it goes out, so
what?

(The 2.6.28 cycle has already started, so it's probably easier to just
leave it alone)

> We *really* don't want 2008.3-rc4 to be followed by 2009.1-rc5.
> That is the kind of stuff that make script makers want to strangle
> developers alive with their own intestines.

+1

Not that I care one way or the other.  It's just that I don't see how
your response bears any relationship with the point Greg made.  It's
just a distraction.  We're talking about how to label releases, not
about guessing the release date of a kernel months ahead.  One you
label it, it stays that way.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member       ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-19 19:51                         ` Jan Engelhardt
@ 2008-10-19 23:40                           ` david
  0 siblings, 0 replies; 111+ messages in thread
From: david @ 2008-10-19 23:40 UTC (permalink / raw)
  To: Jan Engelhardt
  Cc: Greg KH, Alan Cox, Steven Noonan, Adrian Bunk, Linus Torvalds,
	linux-kernel

On Sun, 19 Oct 2008, Jan Engelhardt wrote:

> On Sunday 2008-10-19 14:33, Greg KH wrote:
>>>
>>> If there is a real discontent about the version
>>> number it would have already been changed.
>         ^{on Linus's side}
>>> Given that nothing happened, it seems it is tolerated.

he is the one who raised the subject, so there is discontent. Linus asked 
the question of what to move to.

David Lang

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-19 18:33                       ` Greg KH
@ 2008-10-19 19:51                         ` Jan Engelhardt
  2008-10-19 23:40                           ` david
  0 siblings, 1 reply; 111+ messages in thread
From: Jan Engelhardt @ 2008-10-19 19:51 UTC (permalink / raw)
  To: Greg KH
  Cc: Alan Cox, Steven Noonan, Adrian Bunk, Linus Torvalds, linux-kernel


On Sunday 2008-10-19 14:33, Greg KH wrote:
>> 
>> If there is a real discontent about the version
>> number it would have already been changed.
         ^{on Linus's side}
>> Given that nothing happened, it seems it is tolerated.
>
>Huh?  I'm showing discontent here.  Is that not "real"?

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18 22:33                     ` Jan Engelhardt
@ 2008-10-19 18:33                       ` Greg KH
  2008-10-19 19:51                         ` Jan Engelhardt
  0 siblings, 1 reply; 111+ messages in thread
From: Greg KH @ 2008-10-19 18:33 UTC (permalink / raw)
  To: Jan Engelhardt
  Cc: Alan Cox, Steven Noonan, Adrian Bunk, Linus Torvalds, linux-kernel

On Sat, Oct 18, 2008 at 06:33:52PM -0400, Jan Engelhardt wrote:
> 
> On Wed 2008-10-15 17:25:09 -0700, Grek KH wrote to Linus Torvalds:
> >
> >You brought this topic up a few months ago, and passed it off as
> >something we would discuss at the kernel summit. 
> 
> On Friday 2008-10-17 17:44, Greg KH wrote:
> >
> >Seriously, am I the only one that is getting annoyed by our version
> >numbers?  If so, I can live with it, but I got the feeling that I wasn't
> >alone here.
> 
> 
> If there is a real discontent about the version number
> it would have already been changed.
> Given that nothing happened, it seems it is tolerated.

Huh?  I'm showing discontent here.  Is that not "real"?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-19 17:47                                 ` david
@ 2008-10-19 17:57                                   ` Rafael J. Wysocki
  0 siblings, 0 replies; 111+ messages in thread
From: Rafael J. Wysocki @ 2008-10-19 17:57 UTC (permalink / raw)
  To: david
  Cc: Jiri Kosina, Greg KH, Alan Cox, Steven Noonan, Adrian Bunk,
	Linus Torvalds, linux-kernel

On Sunday, 19 of October 2008, david@lang.hm wrote:
> On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
> 
> > On Sunday, 19 of October 2008, david@lang.hm wrote:
> >> On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
> >>
> >>> On Sunday, 19 of October 2008, Jiri Kosina wrote:
> >>>> On Fri, 17 Oct 2008, david@lang.hm wrote:
> >>>>
> >>>>>> Surely some scripts will start to break as soon as the third number gets
> >>>>>> three digits.
> >>>>> we've had three digit numbers in the third position before (2.3 and 2.5
> >>>>> went well past three digits IIRC)
> >>>>
> >>>> Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special
> >>>> 2.3.99 release).
> >>>>
> >>>>>> Actually, I thought we could continue to use a w.x.y.z numbering
> >>>>>> scheme, but in such a way that:
> >>>>>> w = ($year - 2000) / 10 + 2 (so that we start from 2)
> >>>>>> x = $year % 10
> >>>>>> y = (number of major release in $year)
> >>>>>> z = (number of stable version for major release w.x.y)
> >>>>>> Then, the first major release in 2009 would be 2.9.1 and its first
> >>>>>> -stable "child" would become 2.9.1.1.  In turn, the first major
> >>>>>> release in 2010 could be 3.0.1 and so on.
> >>>>> if you want the part of the version number to increment based on the year,
> >>>>> just make it the year and don't complicate things.
> >>>>
> >>>> In addition to that, having the kernel version dependent on year doesn't
> >>>> really seem to make much sense to me. Simply said, I don't see any
> >>>> relation of kernel source code contents to the current date in whatever
> >>>> calendar system.
> >>>>
> >>>> And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes :)
> >>>
> >>> Hm, why would that happen?
> >>
> >> with the date based numbers, that was one of the things that 'could'
> >> happen as the year changed (2008.5.0-rc4 would be followed by
> >> 2009.1.0-rc5)
> >
> > Well, in that case I think it would be reasonable to cuntinue the 2008
> > numbering so that 2009.1.0-rc5 in your example would still be 2008.5.0-rc5.
> >
> > That said, I kind of agree that the numbering need not be time-related.  One
> > alternative might be to release 2.9.0 instead of 2.6.29 and then continue in
> > in such a way that each of the three numbers is always a one-digit decimal.
> > Then, we'd have 2.9.0, 2.9.1 ... 2.9.9, 3.0.0, 3.0.1 etc.
> 
> so how would you do the -stable releases?

In the same way as they are done now, ie. 2.9.0.1, 2.9.0.2 etc.  I don't think
there's any problem with having 2.9.1.33 for example. ;-)

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-19 17:45                               ` Rafael J. Wysocki
@ 2008-10-19 17:47                                 ` david
  2008-10-19 17:57                                   ` Rafael J. Wysocki
  0 siblings, 1 reply; 111+ messages in thread
From: david @ 2008-10-19 17:47 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Jiri Kosina, Greg KH, Alan Cox, Steven Noonan, Adrian Bunk,
	Linus Torvalds, linux-kernel

On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:

> On Sunday, 19 of October 2008, david@lang.hm wrote:
>> On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
>>
>>> On Sunday, 19 of October 2008, Jiri Kosina wrote:
>>>> On Fri, 17 Oct 2008, david@lang.hm wrote:
>>>>
>>>>>> Surely some scripts will start to break as soon as the third number gets
>>>>>> three digits.
>>>>> we've had three digit numbers in the third position before (2.3 and 2.5
>>>>> went well past three digits IIRC)
>>>>
>>>> Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special
>>>> 2.3.99 release).
>>>>
>>>>>> Actually, I thought we could continue to use a w.x.y.z numbering
>>>>>> scheme, but in such a way that:
>>>>>> w = ($year - 2000) / 10 + 2 (so that we start from 2)
>>>>>> x = $year % 10
>>>>>> y = (number of major release in $year)
>>>>>> z = (number of stable version for major release w.x.y)
>>>>>> Then, the first major release in 2009 would be 2.9.1 and its first
>>>>>> -stable "child" would become 2.9.1.1.  In turn, the first major
>>>>>> release in 2010 could be 3.0.1 and so on.
>>>>> if you want the part of the version number to increment based on the year,
>>>>> just make it the year and don't complicate things.
>>>>
>>>> In addition to that, having the kernel version dependent on year doesn't
>>>> really seem to make much sense to me. Simply said, I don't see any
>>>> relation of kernel source code contents to the current date in whatever
>>>> calendar system.
>>>>
>>>> And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes :)
>>>
>>> Hm, why would that happen?
>>
>> with the date based numbers, that was one of the things that 'could'
>> happen as the year changed (2008.5.0-rc4 would be followed by
>> 2009.1.0-rc5)
>
> Well, in that case I think it would be reasonable to cuntinue the 2008
> numbering so that 2009.1.0-rc5 in your example would still be 2008.5.0-rc5.
>
> That said, I kind of agree that the numbering need not be time-related.  One
> alternative might be to release 2.9.0 instead of 2.6.29 and then continue in
> in such a way that each of the three numbers is always a one-digit decimal.
> Then, we'd have 2.9.0, 2.9.1 ... 2.9.9, 3.0.0, 3.0.1 etc.

so how would you do the -stable releases?

David Lang

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-19 16:29                             ` david
@ 2008-10-19 17:45                               ` Rafael J. Wysocki
  2008-10-19 17:47                                 ` david
  0 siblings, 1 reply; 111+ messages in thread
From: Rafael J. Wysocki @ 2008-10-19 17:45 UTC (permalink / raw)
  To: david
  Cc: Jiri Kosina, Greg KH, Alan Cox, Steven Noonan, Adrian Bunk,
	Linus Torvalds, linux-kernel

On Sunday, 19 of October 2008, david@lang.hm wrote:
> On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:
> 
> > On Sunday, 19 of October 2008, Jiri Kosina wrote:
> >> On Fri, 17 Oct 2008, david@lang.hm wrote:
> >>
> >>>> Surely some scripts will start to break as soon as the third number gets
> >>>> three digits.
> >>> we've had three digit numbers in the third position before (2.3 and 2.5
> >>> went well past three digits IIRC)
> >>
> >> Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special
> >> 2.3.99 release).
> >>
> >>>> Actually, I thought we could continue to use a w.x.y.z numbering
> >>>> scheme, but in such a way that:
> >>>> w = ($year - 2000) / 10 + 2 (so that we start from 2)
> >>>> x = $year % 10
> >>>> y = (number of major release in $year)
> >>>> z = (number of stable version for major release w.x.y)
> >>>> Then, the first major release in 2009 would be 2.9.1 and its first
> >>>> -stable "child" would become 2.9.1.1.  In turn, the first major
> >>>> release in 2010 could be 3.0.1 and so on.
> >>> if you want the part of the version number to increment based on the year,
> >>> just make it the year and don't complicate things.
> >>
> >> In addition to that, having the kernel version dependent on year doesn't
> >> really seem to make much sense to me. Simply said, I don't see any
> >> relation of kernel source code contents to the current date in whatever
> >> calendar system.
> >>
> >> And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes :)
> >
> > Hm, why would that happen?
> 
> with the date based numbers, that was one of the things that 'could' 
> happen as the year changed (2008.5.0-rc4 would be followed by 
> 2009.1.0-rc5)

Well, in that case I think it would be reasonable to cuntinue the 2008
numbering so that 2009.1.0-rc5 in your example would still be 2008.5.0-rc5.

That said, I kind of agree that the numbering need not be time-related.  One
alternative might be to release 2.9.0 instead of 2.6.29 and then continue in
in such a way that each of the three numbers is always a one-digit decimal.
Then, we'd have 2.9.0, 2.9.1 ... 2.9.9, 3.0.0, 3.0.1 etc.

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-19 12:51                           ` Rafael J. Wysocki
@ 2008-10-19 16:29                             ` david
  2008-10-19 17:45                               ` Rafael J. Wysocki
  0 siblings, 1 reply; 111+ messages in thread
From: david @ 2008-10-19 16:29 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Jiri Kosina, Greg KH, Alan Cox, Steven Noonan, Adrian Bunk,
	Linus Torvalds, linux-kernel

On Sun, 19 Oct 2008, Rafael J. Wysocki wrote:

> On Sunday, 19 of October 2008, Jiri Kosina wrote:
>> On Fri, 17 Oct 2008, david@lang.hm wrote:
>>
>>>> Surely some scripts will start to break as soon as the third number gets
>>>> three digits.
>>> we've had three digit numbers in the third position before (2.3 and 2.5
>>> went well past three digits IIRC)
>>
>> Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special
>> 2.3.99 release).
>>
>>>> Actually, I thought we could continue to use a w.x.y.z numbering
>>>> scheme, but in such a way that:
>>>> w = ($year - 2000) / 10 + 2 (so that we start from 2)
>>>> x = $year % 10
>>>> y = (number of major release in $year)
>>>> z = (number of stable version for major release w.x.y)
>>>> Then, the first major release in 2009 would be 2.9.1 and its first
>>>> -stable "child" would become 2.9.1.1.  In turn, the first major
>>>> release in 2010 could be 3.0.1 and so on.
>>> if you want the part of the version number to increment based on the year,
>>> just make it the year and don't complicate things.
>>
>> In addition to that, having the kernel version dependent on year doesn't
>> really seem to make much sense to me. Simply said, I don't see any
>> relation of kernel source code contents to the current date in whatever
>> calendar system.
>>
>> And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes :)
>
> Hm, why would that happen?

with the date based numbers, that was one of the things that 'could' 
happen as the year changed (2008.5.0-rc4 would be followed by 
2009.1.0-rc5)

David Lang

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18 23:14                         ` Jiri Kosina
  2008-10-19  1:50                           ` david
@ 2008-10-19 12:51                           ` Rafael J. Wysocki
  2008-10-19 16:29                             ` david
  1 sibling, 1 reply; 111+ messages in thread
From: Rafael J. Wysocki @ 2008-10-19 12:51 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: david, Greg KH, Alan Cox, Steven Noonan, Adrian Bunk,
	Linus Torvalds, linux-kernel

On Sunday, 19 of October 2008, Jiri Kosina wrote:
> On Fri, 17 Oct 2008, david@lang.hm wrote:
> 
> > > Surely some scripts will start to break as soon as the third number gets
> > > three digits.
> > we've had three digit numbers in the third position before (2.3 and 2.5 
> > went well past three digits IIRC)
> 
> Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special 
> 2.3.99 release).
> 
> > > Actually, I thought we could continue to use a w.x.y.z numbering 
> > > scheme, but in such a way that:
> > > w = ($year - 2000) / 10 + 2 (so that we start from 2)
> > > x = $year % 10
> > > y = (number of major release in $year)
> > > z = (number of stable version for major release w.x.y)
> > > Then, the first major release in 2009 would be 2.9.1 and its first 
> > > -stable "child" would become 2.9.1.1.  In turn, the first major 
> > > release in 2010 could be 3.0.1 and so on.
> > if you want the part of the version number to increment based on the year,
> > just make it the year and don't complicate things.
> 
> In addition to that, having the kernel version dependent on year doesn't 
> really seem to make much sense to me. Simply said, I don't see any 
> relation of kernel source code contents to the current date in whatever 
> calendar system.
> 
> And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes :)

Hm, why would that happen?

Rafael

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18 23:17                       ` Jiri Kosina
@ 2008-10-19  3:35                         ` Willy Tarreau
  0 siblings, 0 replies; 111+ messages in thread
From: Willy Tarreau @ 2008-10-19  3:35 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Greg KH, Alan Cox, Steven Noonan, Adrian Bunk, Linus Torvalds,
	linux-kernel

On Sun, Oct 19, 2008 at 01:17:19AM +0200, Jiri Kosina wrote:
> On Sat, 18 Oct 2008, Willy Tarreau wrote:
> 
> > confusion between 2.4.37 and 2.6.27. I have already tagged kernels with 
> > wrong versions, having to fix by hand afterwards. It's really cumbersome 
> > some times.
> 
> But this is only because you are maintaining a source code that is several 
> years old, right?

It has nothing to do with age, but with the number of digits. Having 4 series
of digits is not easy, especially when some of them are two-digits large.
2.6.26.25-rc1 and 2.6.25.26-rc1 are obviously confusing and not old (not
even released).

> Would maintaining a series numbered 2002.x.y make your 
> situation a lot better? Do you think you'd never make typo '2002 instead 
> of 2006' any more?

Yes I probably would, and I already said I would not like such a numbering
which is even worse IMHO. I'm for small number of digits, X.Y[.Z] with both
X and Y < 10, and Z the stable release. In 22 years, X will go to 10 which
is still not a problem.

> Or how would you distingiush the kernel tree you are maintaing from the 
> one Linus is maintaining?

Another reason why I don't like dates. It makes forked versions more
confusing. Assuming that in 10 years we get 40 versions further, we
might be at version 6.8 and maybe I would have switched to maintain
"old" version 4.2. There is no confusion here.

BTW, speaking about dates, I noticed that others have experimented
with dates and finally changed their mind. Even microsoft. Remember
windows 3.1/3.11 ? In parallel, you had NT 3.5. After that you got
windows 95 (year of predicted release), then 98 (idem). In parallel,
NT went to 4.0. Then they merged all of them into windows 2000,
dropping the versions. Then they started inventing stupid names
like ME, Xp, Vista, ... and now they're talking about windows 7,
which should take its version from the kernel, because the kernel
has kept being versionned "normally" (no marketting involved in
this area). So they might have noticed that using years makes the
whole thing more complex for everyone in the long term. They get
laughed at when releases are delayed, people don't really know if
their seemingly old "2003" is really old or the last one, etc...

Probably that using dates in packaged products such as distros
based on whatever is available at the given date and meant to
evolve quickly and not being supported for long is good however.
It's just a snapshot at a given date and nothing more.

Willy


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-19  1:52       ` david
@ 2008-10-19  2:44         ` Jan Engelhardt
  0 siblings, 0 replies; 111+ messages in thread
From: Jan Engelhardt @ 2008-10-19  2:44 UTC (permalink / raw)
  To: david; +Cc: Thorsten Leemhuis, Greg KH, Linus Torvalds, linux-kernel


On Saturday 2008-10-18 21:52, david@lang.hm wrote:
>> >
>> > pick a name when the merge window opens
>>
>> Hell no, we're not a distro.
>
> huh?
>
> we are picking the name for the next kernel far more in advance today (we know
> that the next kernel will be named 2.6.28, and the one after thta 2.6.29)

"name" is not the same as "version". When you say name, I get this:

	$ grep NAME Makefile 
	NAME = Rotary Wombat

and we, hey, we already have names!

> I'm just saying, pick the name/number for the kernel based on when the merge
> window opened.

Yeah. I mean that's how it was done so far :)

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18 21:44     ` Jan Engelhardt
@ 2008-10-19  1:52       ` david
  2008-10-19  2:44         ` Jan Engelhardt
  0 siblings, 1 reply; 111+ messages in thread
From: david @ 2008-10-19  1:52 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Thorsten Leemhuis, Greg KH, Linus Torvalds, linux-kernel

On Sat, 18 Oct 2008, Jan Engelhardt wrote:

> On Thursday 2008-10-16 03:34, david@lang.hm wrote:
>> On Thu, 16 Oct 2008, Thorsten Leemhuis wrote:
>>> On 16.10.2008 02:25, Greg KH wrote:
>>>
>>> Hence people that write a lot of articles about things that happen in linux
>>> land (like LWN.net or I do) would be forced to write sentences like "[...]the
>>> kernel that will become 2008.3 or 2009.0 will have feature foo that works
>>> like this[...]". That will get really confusing if you read those articles
>>> half a year later -- especially if that kernel became 2008.3 in the end,
>>> because foo in 2009.0 might already look quite different again...
>>
>> pick a name when the merge window opens
>
> Hell no, we're not a distro.

huh?

we are picking the name for the next kernel far more in advance today (we 
know that the next kernel will be named 2.6.28, and the one after thta 
2.6.29)

I'm just saying, pick the name/number for the kernel based on when the 
merge window opened.

if it's the first merge window in 2009 the kernel would be 2009.1.0, if 
it's the 5th merge window it would be 2009.5.0, even if the resulting 
kernel ended up getting released in 2010

David Lang

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18 23:14                         ` Jiri Kosina
@ 2008-10-19  1:50                           ` david
  2008-10-19 12:51                           ` Rafael J. Wysocki
  1 sibling, 0 replies; 111+ messages in thread
From: david @ 2008-10-19  1:50 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Rafael J. Wysocki, Greg KH, Alan Cox, Steven Noonan, Adrian Bunk,
	Linus Torvalds, linux-kernel

On Sun, 19 Oct 2008, Jiri Kosina wrote:

> On Fri, 17 Oct 2008, david@lang.hm wrote:
>
>>> Surely some scripts will start to break as soon as the third number gets
>>> three digits.
>> we've had three digit numbers in the third position before (2.3 and 2.5
>> went well past three digits IIRC)
>
> Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special
> 2.3.99 release).

I know some versions have (I remember deploying 2.1.116 on a box across 
the country with no way to get at it afterwords)

>>> Actually, I thought we could continue to use a w.x.y.z numbering
>>> scheme, but in such a way that:
>>> w = ($year - 2000) / 10 + 2 (so that we start from 2)
>>> x = $year % 10
>>> y = (number of major release in $year)
>>> z = (number of stable version for major release w.x.y)
>>> Then, the first major release in 2009 would be 2.9.1 and its first
>>> -stable "child" would become 2.9.1.1.  In turn, the first major
>>> release in 2010 could be 3.0.1 and so on.
>> if you want the part of the version number to increment based on the year,
>> just make it the year and don't complicate things.
>
> In addition to that, having the kernel version dependent on year doesn't
> really seem to make much sense to me. Simply said, I don't see any
> relation of kernel source code contents to the current date in whatever
> calendar system.

it does give an indication of how out of date the kernel you are using is.

> And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes :)

that I agree with.

David Lang

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18  8:45                     ` Willy Tarreau
@ 2008-10-18 23:17                       ` Jiri Kosina
  2008-10-19  3:35                         ` Willy Tarreau
  2008-10-20 20:30                       ` Greg KH
  1 sibling, 1 reply; 111+ messages in thread
From: Jiri Kosina @ 2008-10-18 23:17 UTC (permalink / raw)
  To: Willy Tarreau
  Cc: Greg KH, Alan Cox, Steven Noonan, Adrian Bunk, Linus Torvalds,
	linux-kernel

On Sat, 18 Oct 2008, Willy Tarreau wrote:

> confusion between 2.4.37 and 2.6.27. I have already tagged kernels with 
> wrong versions, having to fix by hand afterwards. It's really cumbersome 
> some times.

But this is only because you are maintaining a source code that is several 
years old, right? Would maintaining a series numbered 2002.x.y make your 
situation a lot better? Do you think you'd never make typo '2002 instead 
of 2006' any more?

Or how would you distingiush the kernel tree you are maintaing from the 
one Linus is maintaining?

-- 
Jiri Kosina
SUSE Labs


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18  1:23                       ` david
@ 2008-10-18 23:14                         ` Jiri Kosina
  2008-10-19  1:50                           ` david
  2008-10-19 12:51                           ` Rafael J. Wysocki
  0 siblings, 2 replies; 111+ messages in thread
From: Jiri Kosina @ 2008-10-18 23:14 UTC (permalink / raw)
  To: david
  Cc: Rafael J. Wysocki, Greg KH, Alan Cox, Steven Noonan, Adrian Bunk,
	Linus Torvalds, linux-kernel

On Fri, 17 Oct 2008, david@lang.hm wrote:

> > Surely some scripts will start to break as soon as the third number gets
> > three digits.
> we've had three digit numbers in the third position before (2.3 and 2.5 
> went well past three digits IIRC)

Did we? I only recall 2.5.7[something] and 2.3.5[something] (plus special 
2.3.99 release).

> > Actually, I thought we could continue to use a w.x.y.z numbering 
> > scheme, but in such a way that:
> > w = ($year - 2000) / 10 + 2 (so that we start from 2)
> > x = $year % 10
> > y = (number of major release in $year)
> > z = (number of stable version for major release w.x.y)
> > Then, the first major release in 2009 would be 2.9.1 and its first 
> > -stable "child" would become 2.9.1.1.  In turn, the first major 
> > release in 2010 could be 3.0.1 and so on.
> if you want the part of the version number to increment based on the year,
> just make it the year and don't complicate things.

In addition to that, having the kernel version dependent on year doesn't 
really seem to make much sense to me. Simply said, I don't see any 
relation of kernel source code contents to the current date in whatever 
calendar system.

And 2.x+1.y-rcZ+1 immediately following 2.x.y-rcZ really hurts my eyes :)

-- 
Jiri Kosina
SUSE Labs


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 21:44                   ` Greg KH
                                       ` (3 preceding siblings ...)
  2008-10-18 22:33                     ` Jan Engelhardt
@ 2008-10-18 22:38                     ` Jan Engelhardt
  4 siblings, 0 replies; 111+ messages in thread
From: Jan Engelhardt @ 2008-10-18 22:38 UTC (permalink / raw)
  To: Greg KH
  Cc: Alan Cox, Steven Noonan, Adrian Bunk, Linus Torvalds, linux-kernel


On Friday 2008-10-17 17:44, Greg KH wrote:
>
>Sure, but by then, the 2.6.521 release will be out and we could fix it
>up by finally going to 3.0 :)

There will be no 2.6.521. Simply because the LINUX_VERSION_CODE
macro only allows for the 2nd and 3rd position to be 8 bits.

(Hooray, which means we will _automatically_ get a 2.7 after at most
229 more releases, or 3.0 after at most 63973 more releases!^{*})


{*} If you find off-by-one errors, keep them.

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 21:44                   ` Greg KH
                                       ` (2 preceding siblings ...)
  2008-10-18  8:45                     ` Willy Tarreau
@ 2008-10-18 22:33                     ` Jan Engelhardt
  2008-10-19 18:33                       ` Greg KH
  2008-10-18 22:38                     ` Jan Engelhardt
  4 siblings, 1 reply; 111+ messages in thread
From: Jan Engelhardt @ 2008-10-18 22:33 UTC (permalink / raw)
  To: Greg KH
  Cc: Alan Cox, Steven Noonan, Adrian Bunk, Linus Torvalds, linux-kernel


On Wed 2008-10-15 17:25:09 -0700, Grek KH wrote to Linus Torvalds:
>
>You brought this topic up a few months ago, and passed it off as
>something we would discuss at the kernel summit. 

On Friday 2008-10-17 17:44, Greg KH wrote:
>
>Seriously, am I the only one that is getting annoyed by our version
>numbers?  If so, I can live with it, but I got the feeling that I wasn't
>alone here.


If there is a real discontent about the version number
it would have already been changed.
Given that nothing happened, it seems it is tolerated.

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  9:15 ` Hans J. Koch
  2008-10-16 15:21   ` Geert Uytterhoeven
@ 2008-10-18 21:56   ` Jan Engelhardt
  1 sibling, 0 replies; 111+ messages in thread
From: Jan Engelhardt @ 2008-10-18 21:56 UTC (permalink / raw)
  To: Hans J. Koch; +Cc: Greg KH, Linus Torvalds, linux-kernel


On Thursday 2008-10-16 05:15, Hans J. Koch wrote:
>On Wed, Oct 15, 2008 at 05:25:09PM -0700, Greg KH wrote:
>> 
>> Benefits of this is it more accuratly represents to people just how old
>> the kernel they are currently running is (2.6.9 would be have been
>> 2004.9.0 on this naming scheme.)
>
>That would be a nice advantage, especially in embedded land where
>industry people frequently use ancient kernels. OTOH, those people also
>still use Windows 2000 without realizing what the "2000" implies.

(It implies 1999.)

If people do not even realize what "Windows 2000" means,
how would they be able to realize what "Linux 2004" would!

Also, Windows long moved away from the year-numbering (XP, Vista, and
the next is probably going to be an increasing integer), because
Redmond probably figured that people don't realize anything.

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  7:34   ` david
@ 2008-10-18 21:44     ` Jan Engelhardt
  2008-10-19  1:52       ` david
  0 siblings, 1 reply; 111+ messages in thread
From: Jan Engelhardt @ 2008-10-18 21:44 UTC (permalink / raw)
  To: david; +Cc: Thorsten Leemhuis, Greg KH, Linus Torvalds, linux-kernel


On Thursday 2008-10-16 03:34, david@lang.hm wrote:
> On Thu, 16 Oct 2008, Thorsten Leemhuis wrote:
>> On 16.10.2008 02:25, Greg KH wrote:
>>
>> Hence people that write a lot of articles about things that happen in linux
>> land (like LWN.net or I do) would be forced to write sentences like "[...]the
>> kernel that will become 2008.3 or 2009.0 will have feature foo that works
>> like this[...]". That will get really confusing if you read those articles
>> half a year later -- especially if that kernel became 2008.3 in the end,
>> because foo in 2009.0 might already look quite different again...
>
> pick a name when the merge window opens

Hell no, we're not a distro.

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18 13:48                         ` Adrian Bunk
@ 2008-10-18 14:13                           ` Willy Tarreau
  0 siblings, 0 replies; 111+ messages in thread
From: Willy Tarreau @ 2008-10-18 14:13 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Greg KH, Linus Torvalds, linux-kernel

On Sat, Oct 18, 2008 at 04:48:33PM +0300, Adrian Bunk wrote:
> 10 years ago someone wrote his own version of config.guess, and assumed 
> kernel developers would always use sane versions.

And versions are not sane anymore. 1.0, 1.2, 2.0, 2.2 and 2.4 were branches
where the 3rd digit indicated a patch level or a minor feature enhancement.
Yes there were exceptions to that. 2.2.18 brought USB. 2.4.10 changed the
VM, the list can be extended. But the principle was that $MAJOR.$MINOR
could be relied on. It's not the case anymore. You have to check 3 numbers
now if you want to check for some specific feature. I think that only /sys
existence and the module loading method are constants across all 2.6.

Getting back to something like $MAJOR.$MINOR would not change the original
checks. New versions would have to be updated once in a while if needed,
just like we'd have to if 2.6.29 brought a great change.

I'm clearly not for anything depending on the date. But having 3.0 instead
of 2.6.30, then 3.1, 3.2, ... would have no reason to break a model which
has worked well for the last 15 years.

> A "just for fun" change of the version number will break existing 
> programs, and that will cause various problems for various people.

It's not "just for fun". You know I'm often more reluctant to changing than
you are. But as Linus already pointed it out, numbers are becoming completely
meaningless and it's a pain to enumerate them. You and I are both playing
with 4-digit versions once in a while. Greg releases two such versions at
once far more often than any of us. This versionning is already confusing.
It's certainly not for fun that Greg brought that subject back.

> > Quite cool stuff, but I'm really not interested. Having been beat by
> > a number of packages which try to run target environment commands
> > during the build when not set for cross-compile, I'd expect pretty
> > random results.
> 
> The build system of the package thinks it gets compiled natively - that 
> avoids exactly the problems you describe.

Well, the way you describe it with all the magics ("thinks", "transparent",
...) is precisely what incites me to stay away from that. Autoconf is also
made to make things more transparent, and what a mess... But I know you're
attached to clean and reliable things, so I'll take a look at it to get my
own opinion on the solution (not right now though).

Willy


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18 12:28                       ` Willy Tarreau
@ 2008-10-18 13:48                         ` Adrian Bunk
  2008-10-18 14:13                           ` Willy Tarreau
  0 siblings, 1 reply; 111+ messages in thread
From: Adrian Bunk @ 2008-10-18 13:48 UTC (permalink / raw)
  To: Willy Tarreau; +Cc: Greg KH, Linus Torvalds, linux-kernel

On Sat, Oct 18, 2008 at 02:28:51PM +0200, Willy Tarreau wrote:
> On Sat, Oct 18, 2008 at 02:50:38PM +0300, Adrian Bunk wrote:
>...
> > > > Scratchbox [1], e.g. used for building the software in Nokias Internet 
> > > > Tablets [2] or the ARM Linux Internet Platform [3], is a chrooted 
> > > > cross-compilation environment.
> > > > 
> > > > Yes, it works.
> > > 
> > > I'm not saying it does not work, I'm saying it's far from being practical
> > > when you want to support multiple architectures or targets, and that it
> > > will do nasty things under you without letting you know.
> > 
> > Scratchbox easily allows switching between targets, no matter which 
> > architectures they are for.
> > 
> > Can you describe the problems you have experienced more precisely?
> 
> Adrian, don't try to make me look like dumb by asking for specific
> problems. Problems range from auto-detection of kernel version to

> enable or disable feature X or Y,

Works inside Scratchbox.

> to endian detection and bit width

Works inside Scratchbox.

> detection. If you don't believe me, it's just that you're used to
> build completely OS-agnostic packages,

That's completely wrong.

> which is perfectly fine, but
> that doesn't seem to be completely the case given that you're feeling
> you will get annoyed by breaking the openssl BUILD environment if
> you make it run on a different kernel. *That* is the funny part,
> since this build environment should not even require to run on Linux
> at all!

10 years ago someone wrote his own version of config.guess, and assumed 
kernel developers would always use sane versions.

This doesn't make it Linux-specific.

>...
> > > A build environment is what it is, a build environment. It contains
> > > compilers, shells to run scripts, various interpreters and build tools,
> > > possibily debuggers and editors, versionning systems, etc...
> > 
> > The build environment in the chroot is the correct release.    
> 
> No it isn't because you're saying that some of the packages check for
> kernel version which is not the right one. So if you move your chroot
> to another machine, it is susceptible to break because it relies on
> the host's kernel version. So your chroot is not your build environment,
> it's just part of it.

The version is one of the few things the kernel leaks inside a chroot.

> > > > Userspace ABIs of the kernel are usually stable.
> > > 
> > > Yes but they are not necessarily forward-compatible. If openssl believes
> > > some feature is present in 2.6.521 because 521 is bigger than 233, you
> > > will build a broken package which will not work with any distro running
> > > your long-term 2.6.27 which does not have the feature introduced in .233.
> > 
> > I already addressed this previously in this thread:
> > 
> > I'm not even sure whether OpenSSL actually does anything with the 
> > information: The script comes from the Apache foundation and
> > claims to be "Similar to config.guess but much, much smaller."
> 
> You addressed it only for openssl and apache 1.3, that you used as
> examples to object to a change of changing kernel version numbering
> scheme. So do you have other examples of packages like this which
> might break and might be more sensible to build environment's kernel
> version ? Because if only apache 1.3 and openssl 0.9.8g are sensible,
> the fix will be really quick using something like this in your build
> scripts and makefiles :
>...
> And BTW, if your build environment mimmics so well the target except
> for uname, let's fix its uname tool to reflect the target version !

The problem has nothing to do with any build environments or chroots.

A "just for fun" change of the version number will break existing 
programs, and that will cause various problems for various people.

> > > And when
> > > you know how to fix packages so that chroot is not a problem, then you
> > > know how to fix the package not to require a chroot.
> > 
> > That's complete bullshit:
> > 
> > Packages do not require fixes for being built inside a chroot.
> > 
> > Given:
> > - some software package of a foobar program
> > - Scratchbox on an x86 host
> > - an ARM target that mounts the target filesystem from the host
> > 
> > host   # ./configure && make && make install
> > target # foobar
> > 
> > The build system of the software thinks it gets built on the target 
> > architecture.
> 
> Quite cool stuff, but I'm really not interested. Having been beat by
> a number of packages which try to run target environment commands
> during the build when not set for cross-compile, I'd expect pretty
> random results.

The build system of the package thinks it gets compiled natively - that 
avoids exactly the problems you describe.

And trying to run a target binary when building on the host *does work* 
inside Scratchbox. Please *read* what I wrote directly below:

> > And due to transparent usage of qemu or sbrsh it also works when the 
> > package uses a program built for the target during the build.
> > No matter whether the build system of the package knows anything about
> > cross-compilation.
>...
> Willy

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18 11:50                     ` Adrian Bunk
@ 2008-10-18 12:28                       ` Willy Tarreau
  2008-10-18 13:48                         ` Adrian Bunk
  0 siblings, 1 reply; 111+ messages in thread
From: Willy Tarreau @ 2008-10-18 12:28 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Greg KH, Linus Torvalds, linux-kernel

On Sat, Oct 18, 2008 at 02:50:38PM +0300, Adrian Bunk wrote:
> > this is becoming off-topic, but there are some points which need to be
> > addressed. Please if you want to reply afterwards, be kind to strip the
> > CC list.
> 
> sorry, but you can't publically spread misinformation (and even repeat 
> wrong things I already replied to earlier in this thread) and then 
> demand to not have the reply public.

It's not about not having it public, it's about not flooding people's
mailboxes with off-topic mails.

> > On Sat, Oct 18, 2008 at 01:04:01PM +0300, Adrian Bunk wrote:
> > I'm not judging that, they build like they want. If they want to build
> > on the final target and have as many build machines as they support,
> > it's their problem. It's just very amateurish.
> 
> Debian does it, it works, and there's nothing amateurish about it - it's 
> much easier than coping with all the problems faced with when trying to 
> cross-compile > 12.000 source packages.

It's easier as long as you have one build environment very close to the
target, which tends not to be possible anymore as time passes or for too
small devices.

> With <= 3 build machines per architecture.

and why not have 3 build machines at all ?

> > > Scratchbox [1], e.g. used for building the software in Nokias Internet 
> > > Tablets [2] or the ARM Linux Internet Platform [3], is a chrooted 
> > > cross-compilation environment.
> > > 
> > > Yes, it works.
> > 
> > I'm not saying it does not work, I'm saying it's far from being practical
> > when you want to support multiple architectures or targets, and that it
> > will do nasty things under you without letting you know.
> 
> Scratchbox easily allows switching between targets, no matter which 
> architectures they are for.
> 
> Can you describe the problems you have experienced more precisely?

Adrian, don't try to make me look like dumb by asking for specific
problems. Problems range from auto-detection of kernel version to
enable or disable feature X or Y, to endian detection and bit width
detection. If you don't believe me, it's just that you're used to
build completely OS-agnostic packages, which is perfectly fine, but
that doesn't seem to be completely the case given that you're feeling
you will get annoyed by breaking the openssl BUILD environment if
you make it run on a different kernel. *That* is the funny part,
since this build environment should not even require to run on Linux
at all! And believe me, I know that openssl is boring to build due
to many hard-coded things which require patching (mainly paths if my
memory is correct). But once that's done, it's done forever.

> > A build environment is what it is, a build environment. It contains
> > compilers, shells to run scripts, various interpreters and build tools,
> > possibily debuggers and editors, versionning systems, etc...
> 
> The build environment in the chroot is the correct release.    

No it isn't because you're saying that some of the packages check for
kernel version which is not the right one. So if you move your chroot
to another machine, it is susceptible to break because it relies on
the host's kernel version. So your chroot is not your build environment,
it's just part of it.

> > > Userspace ABIs of the kernel are usually stable.
> > 
> > Yes but they are not necessarily forward-compatible. If openssl believes
> > some feature is present in 2.6.521 because 521 is bigger than 233, you
> > will build a broken package which will not work with any distro running
> > your long-term 2.6.27 which does not have the feature introduced in .233.
> 
> I already addressed this previously in this thread:
> 
> I'm not even sure whether OpenSSL actually does anything with the 
> information: The script comes from the Apache foundation and
> claims to be "Similar to config.guess but much, much smaller."

You addressed it only for openssl and apache 1.3, that you used as
examples to object to a change of changing kernel version numbering
scheme. So do you have other examples of packages like this which
might break and might be more sensible to build environment's kernel
version ? Because if only apache 1.3 and openssl 0.9.8g are sensible,
the fix will be really quick using something like this in your build
scripts and makefiles :

uname() {
   if [ -n "$KERNEL_TARGET" ]; then
      echo $KERNEL_TARGET
   else
      /bin/uname "$@"
   fi
}

And BTW, if your build environment mimmics so well the target except
for uname, let's fix its uname tool to reflect the target version !

> > And when
> > you know how to fix packages so that chroot is not a problem, then you
> > know how to fix the package not to require a chroot.
> 
> That's complete bullshit:
> 
> Packages do not require fixes for being built inside a chroot.
> 
> Given:
> - some software package of a foobar program
> - Scratchbox on an x86 host
> - an ARM target that mounts the target filesystem from the host
> 
> host   # ./configure && make && make install
> target # foobar
> 
> The build system of the software thinks it gets built on the target 
> architecture.

Quite cool stuff, but I'm really not interested. Having been beat by
a number of packages which try to run target environment commands
during the build when not set for cross-compile, I'd expect pretty
random results.

> And due to transparent usage of qemu or sbrsh it also works when the 
> package uses a program built for the target during the build.
> No matter whether the build system of the package knows anything about
> cross-compilation.

That's the design error you're trying to fix by pushing constraints on
the kernel.

Willy


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18 11:08                   ` Willy Tarreau
@ 2008-10-18 11:50                     ` Adrian Bunk
  2008-10-18 12:28                       ` Willy Tarreau
  0 siblings, 1 reply; 111+ messages in thread
From: Adrian Bunk @ 2008-10-18 11:50 UTC (permalink / raw)
  To: Willy Tarreau; +Cc: Greg KH, Linus Torvalds, linux-kernel

On Sat, Oct 18, 2008 at 01:08:26PM +0200, Willy Tarreau wrote:
> Hi Adrian,

Hi Willy,

> this is becoming off-topic, but there are some points which need to be
> addressed. Please if you want to reply afterwards, be kind to strip the
> CC list.

sorry, but you can't publically spread misinformation (and even repeat 
wrong things I already replied to earlier in this thread) and then 
demand to not have the reply public.

> On Sat, Oct 18, 2008 at 01:04:01PM +0300, Adrian Bunk wrote:
> > On Sat, Oct 18, 2008 at 11:01:18AM +0200, Willy Tarreau wrote:
> > > On Fri, Oct 17, 2008 at 11:56:04AM +0300, Adrian Bunk wrote:
> > >...
> > > > Building software in a chroot is a common thing if you don't want to 
> > > > setup a dedicated machine for a build environment (and all these hyped 
> > > > virtualization solutions tend to not support architectures like alpha
> > > > or parisc).
> > > 
> > > The chroot is OK when you want to maintain a few packages once in
> > > a while (eg: have it on your notebook to build packages for your
> > > customers' various distros). But it's not suited to maintain full
> > > distros,
> > 
> > You claim Debian was not a full distro?
> 
> I'm not judging that, they build like they want. If they want to build
> on the final target and have as many build machines as they support,
> it's their problem. It's just very amateurish.

Debian does it, it works, and there's nothing amateurish about it - it's 
much easier than coping with all the problems faced with when trying to 
cross-compile > 12.000 source packages.

With <= 3 build machines per architecture.

> I wouldn't like to be
> the guy building the full distro in a chroot on an embedded ARM or MIPS
> just because it's the target.

It's incremental, only a small amount of packages gets changed each day.

> > > nor to cross-compile.
> > 
> > Scratchbox [1], e.g. used for building the software in Nokias Internet 
> > Tablets [2] or the ARM Linux Internet Platform [3], is a chrooted 
> > cross-compilation environment.
> > 
> > Yes, it works.
> 
> I'm not saying it does not work, I'm saying it's far from being practical
> when you want to support multiple architectures or targets, and that it
> will do nasty things under you without letting you know.

Scratchbox easily allows switching between targets, no matter which 
architectures they are for.

Can you describe the problems you have experienced more precisely?

> > And since a few years everyone can buy devices running software built 
> > inside Scratchbox chroots.
> > 
> > > > The OpenSSL 0.9.8 config script is existing userspace, and it will 
> > > > break.
> > > 
> > > And ? All distros shipping version 0.9.8 with a current kernel will
> > > have no problem because they backport fixes only. Once the new kernel
> > > is out, openssl will release a minor update with a few fixes and features,
> > > one of them being tagged as "support for Linux 2.8 and above". New distros
> > > will then have no trouble shipping a standard openssl with a standard
> > > kernel. All software have always worked like this, I really don't see
> > > the problem Adrian.
> > 
> > Since Debian has a "support a release until one year after the next 
> > release" policy, Debian will at some point in the future build security 
> > fixes for OpenSSL 0.9.8g (shipped with Debian 5.0) in chroots on 
> > autobuilders running Debian 6.0 (runing kernel 2010.2.6).
> 
> The process you're describing is frighteningly broken. You're basically
> telling me that the day openssl automatically detects and enables a
> feature in the debian build environment, it will automatically enable
> it for the target environment ?
>...
> A build environment is what it is, a build environment. It contains
> compilers, shells to run scripts, various interpreters and build tools,
> possibily debuggers and editors, versionning systems, etc...

The build environment in the chroot is the correct release.    

But the kernel returns the kernel version in sys_*uname().

> > > > That is one example that "Will" definitely break (no matter how broken 
> > > > or how easy to fix it is).
> > > 
> > > What makes you think that current 0.9.8g will work on 2.6.521 ?
> > >...
> > 
> > Userspace ABIs of the kernel are usually stable.
> 
> Yes but they are not necessarily forward-compatible. If openssl believes
> some feature is present in 2.6.521 because 521 is bigger than 233, you
> will build a broken package which will not work with any distro running
> your long-term 2.6.27 which does not have the feature introduced in .233.

I already addressed this previously in this thread:

I'm not even sure whether OpenSSL actually does anything with the 
information: The script comes from the Apache foundation and
claims to be "Similar to config.guess but much, much smaller."

>...
> And when
> you know how to fix packages so that chroot is not a problem, then you
> know how to fix the package not to require a chroot.

That's complete bullshit:

Packages do not require fixes for being built inside a chroot.

Given:
- some software package of a foobar program
- Scratchbox on an x86 host
- an ARM target that mounts the target filesystem from the host

host   # ./configure && make && make install
target # foobar

The build system of the software thinks it gets built on the target 
architecture.

And due to transparent usage of qemu or sbrsh it also works when the 
package uses a program built for the target during the build.
No matter whether the build system of the package knows anything about 
cross-compilation.

> Willy

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18 10:04                 ` Adrian Bunk
@ 2008-10-18 11:08                   ` Willy Tarreau
  2008-10-18 11:50                     ` Adrian Bunk
  0 siblings, 1 reply; 111+ messages in thread
From: Willy Tarreau @ 2008-10-18 11:08 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Greg KH, Linus Torvalds, linux-kernel

Hi Adrian,

this is becoming off-topic, but there are some points which need to be
addressed. Please if you want to reply afterwards, be kind to strip the
CC list.

On Sat, Oct 18, 2008 at 01:04:01PM +0300, Adrian Bunk wrote:
> On Sat, Oct 18, 2008 at 11:01:18AM +0200, Willy Tarreau wrote:
> > On Fri, Oct 17, 2008 at 11:56:04AM +0300, Adrian Bunk wrote:
> >...
> > > Building software in a chroot is a common thing if you don't want to 
> > > setup a dedicated machine for a build environment (and all these hyped 
> > > virtualization solutions tend to not support architectures like alpha
> > > or parisc).
> > 
> > The chroot is OK when you want to maintain a few packages once in
> > a while (eg: have it on your notebook to build packages for your
> > customers' various distros). But it's not suited to maintain full
> > distros,
> 
> You claim Debian was not a full distro?

I'm not judging that, they build like they want. If they want to build
on the final target and have as many build machines as they support,
it's their problem. It's just very amateurish. I wouldn't like to be
the guy building the full distro in a chroot on an embedded ARM or MIPS
just because it's the target.

> > nor to cross-compile.
> 
> Scratchbox [1], e.g. used for building the software in Nokias Internet 
> Tablets [2] or the ARM Linux Internet Platform [3], is a chrooted 
> cross-compilation environment.
> 
> Yes, it works.

I'm not saying it does not work, I'm saying it's far from being practical
when you want to support multiple architectures or targets, and that it
will do nasty things under you without letting you know.

> And since a few years everyone can buy devices running software built 
> inside Scratchbox chroots.
> 
> > > The OpenSSL 0.9.8 config script is existing userspace, and it will 
> > > break.
> > 
> > And ? All distros shipping version 0.9.8 with a current kernel will
> > have no problem because they backport fixes only. Once the new kernel
> > is out, openssl will release a minor update with a few fixes and features,
> > one of them being tagged as "support for Linux 2.8 and above". New distros
> > will then have no trouble shipping a standard openssl with a standard
> > kernel. All software have always worked like this, I really don't see
> > the problem Adrian.
> 
> Since Debian has a "support a release until one year after the next 
> release" policy, Debian will at some point in the future build security 
> fixes for OpenSSL 0.9.8g (shipped with Debian 5.0) in chroots on 
> autobuilders running Debian 6.0 (runing kernel 2010.2.6).

The process you're describing is frighteningly broken. You're basically
telling me that the day openssl automatically detects and enables a
feature in the debian build environment, it will automatically enable
it for the target environment ? This is pure non-sense. If they build
like that, they'd better keep old boxes running the same distro as the
target to maintain stable releases, or it's urgent to stay away from
their stable versions as soon as you're aware they switched the build
machine ! I hope they don't build 32-bit x86 from 64-bit systems if
they proceed like this...

A build environment is what it is, a build environment. It contains
compilers, shells to run scripts, various interpreters and build tools,
possibily debuggers and editors, versionning systems, etc...

The target environment has nothing to do with the build environment.
It's the environment the binary will run on. If some project does
auto-detection of the build environment assuming it's the same as
the target, you have to force it to the target environment, and not
to dress up the build environment to look like it is the target one.

For instance, I would be very angry if I built a project which
automatically selected the use of epoll() for 2.4 target just
because I'm building on 2.6. And in fact, this seldom happens,
and setting a few variables or even patching configure or makefile
is enough to fix the issue (and it is the right thing to do).

> > > That is one example that "Will" definitely break (no matter how broken 
> > > or how easy to fix it is).
> > 
> > What makes you think that current 0.9.8g will work on 2.6.521 ?
> >...
> 
> Userspace ABIs of the kernel are usually stable.

Yes but they are not necessarily forward-compatible. If openssl believes
some feature is present in 2.6.521 because 521 is bigger than 233, you
will build a broken package which will not work with any distro running
your long-term 2.6.27 which does not have the feature introduced in .233.

Again, chroot builds are cool for *some* things. I too do use them a lot.
But they're very dangerous and must not be used for everything. And when
you know how to fix packages so that chroot is not a problem, then you
know how to fix the package not to require a chroot.

Willy


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-18  9:01               ` Willy Tarreau
@ 2008-10-18 10:04                 ` Adrian Bunk
  2008-10-18 11:08                   ` Willy Tarreau
  0 siblings, 1 reply; 111+ messages in thread
From: Adrian Bunk @ 2008-10-18 10:04 UTC (permalink / raw)
  To: Willy Tarreau; +Cc: Greg KH, Linus Torvalds, linux-kernel

On Sat, Oct 18, 2008 at 11:01:18AM +0200, Willy Tarreau wrote:
> On Fri, Oct 17, 2008 at 11:56:04AM +0300, Adrian Bunk wrote:
>...
> > Building software in a chroot is a common thing if you don't want to 
> > setup a dedicated machine for a build environment (and all these hyped 
> > virtualization solutions tend to not support architectures like alpha
> > or parisc).
> 
> The chroot is OK when you want to maintain a few packages once in
> a while (eg: have it on your notebook to build packages for your
> customers' various distros). But it's not suited to maintain full
> distros,

You claim Debian was not a full distro?

> nor to cross-compile.

Scratchbox [1], e.g. used for building the software in Nokias Internet 
Tablets [2] or the ARM Linux Internet Platform [3], is a chrooted 
cross-compilation environment.

Yes, it works.

And since a few years everyone can buy devices running software built 
inside Scratchbox chroots.

> > The OpenSSL 0.9.8 config script is existing userspace, and it will 
> > break.
> 
> And ? All distros shipping version 0.9.8 with a current kernel will
> have no problem because they backport fixes only. Once the new kernel
> is out, openssl will release a minor update with a few fixes and features,
> one of them being tagged as "support for Linux 2.8 and above". New distros
> will then have no trouble shipping a standard openssl with a standard
> kernel. All software have always worked like this, I really don't see
> the problem Adrian.

Since Debian has a "support a release until one year after the next 
release" policy, Debian will at some point in the future build security 
fixes for OpenSSL 0.9.8g (shipped with Debian 5.0) in chroots on 
autobuilders running Debian 6.0 (runing kernel 2010.2.6).

> > That is one example that "Will" definitely break (no matter how broken 
> > or how easy to fix it is).
> 
> What makes you think that current 0.9.8g will work on 2.6.521 ?
>...

Userspace ABIs of the kernel are usually stable.

There might be special cases like the year 2038 problem, but usually 
breaking an ABI software like OpenSSL uses would be considered a grave 
regression. [4]

> Regards,
> Willy

cu
Adrian

[1] http://scratchbox.org/
[2] http://maemo.org/
[3] http://linux.onarm.com/
[4] note that the value of the kernel version number is not strictly
    a userspace ABI - but changing it in unexpected ways will break
    existing software

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  8:56             ` Adrian Bunk
                                 ` (2 preceding siblings ...)
  2008-10-17 17:45               ` Greg KH
@ 2008-10-18  9:01               ` Willy Tarreau
  2008-10-18 10:04                 ` Adrian Bunk
  3 siblings, 1 reply; 111+ messages in thread
From: Willy Tarreau @ 2008-10-18  9:01 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Greg KH, Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 11:56:04AM +0300, Adrian Bunk wrote:
> On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
> > On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
> >...
> > > Packages are built in a chroot with the correct release installed.
> > 
> > Then why would this break if they are being built against the correct,
> > older, kernel?
> 
> How could you build userspace "against a kernel"?
> 
> sys_*uname() returns the version of the running kernel.

Which is why you don't want your build scripts to rely on that, but
on the target kernel version instead. It's quite common in distros
to patch makefiles and build scripts to force some constants instead
of calls to nasty or misplaced commands. Uname certainly is one of
them.

> > But not against the proper kernel it will be run on, which sounds
> > broken.
> 
> Building software in a chroot is a common thing if you don't want to 
> setup a dedicated machine for a build environment (and all these hyped 
> virtualization solutions tend to not support architectures like alpha
> or parisc).

The chroot is OK when you want to maintain a few packages once in
a while (eg: have it on your notebook to build packages for your
customers' various distros). But it's not suited to maintain full
distros, nor to cross-compile.

> The OpenSSL 0.9.8 config script is existing userspace, and it will 
> break.

And ? All distros shipping version 0.9.8 with a current kernel will
have no problem because they backport fixes only. Once the new kernel
is out, openssl will release a minor update with a few fixes and features,
one of them being tagged as "support for Linux 2.8 and above". New distros
will then have no trouble shipping a standard openssl with a standard
kernel. All software have always worked like this, I really don't see
the problem Adrian.

> That is one example that "Will" definitely break (no matter how broken 
> or how easy to fix it is).

What makes you think that current 0.9.8g will work on 2.6.521 ? One day
you might have to upgrade your openssl anyway. What is important is that
the upgrade follows a smooth path. Adding a two-liner patch in a minor
release to support new versions is smooth.

> > And hey, if it's a problem, just fix userspace reporting to always say
> > we are the 2.6.30 release and go on our merry way, perhaps providing
> > another sysctl if it's really needed (glibc probably wants it, so it
> > would be easy to add.)
> > 
> > That's just a minor technical thing that can be trivially fixed _IF_ we
> > decide it is something that we want to do.
> 
> If we do not continue to report the correct version in sys_*uname()
> (and therefore in "uname -r") we break standard POSIX behavior.

I would not like it if uname -r would not report real version. I'd
better get a tool to force the version if this is needed (ala cpuid).
It reminds me that I had this for years under DOS :-)

Regards,
Willy


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 21:44                   ` Greg KH
  2008-10-17 22:14                     ` Matthias Schniedermeyer
  2008-10-17 22:49                     ` Rafael J. Wysocki
@ 2008-10-18  8:45                     ` Willy Tarreau
  2008-10-18 23:17                       ` Jiri Kosina
  2008-10-20 20:30                       ` Greg KH
  2008-10-18 22:33                     ` Jan Engelhardt
  2008-10-18 22:38                     ` Jan Engelhardt
  4 siblings, 2 replies; 111+ messages in thread
From: Willy Tarreau @ 2008-10-18  8:45 UTC (permalink / raw)
  To: Greg KH
  Cc: Alan Cox, Steven Noonan, Adrian Bunk, Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 02:44:09PM -0700, Greg KH wrote:
> On Fri, Oct 17, 2008 at 08:47:23PM +0100, Alan Cox wrote:
> > > And that's my point here, do we want to change the current numbering
> > > scheme as people have expressed annoyances of the current one.
> > 
> > But any new scheme will be just as annoying to someone and it messes up
> > existing documentation, understanding and risks breaking third party
> > tools.
> > 
> > Is it really worth the hassle, plus we'll have to change again if we use
> > date/times because once we are shipping Linux out to Alpha Centauri with
> > colonists there will be serious problems trying to compute the effect of
> > tau on release numbering ...
> 
> Sure, but by then, the 2.6.521 release will be out and we could fix it
> up by finally going to 3.0 :)
> 
> Seriously, am I the only one that is getting annoyed by our version
> numbers?  If so, I can live with it, but I got the feeling that I wasn't
> alone here.

No you're not. I am too. Maybe we're both more annoyed than majority
because we're mostly dealing with 4-numbers versions.

I remember having recently suggested someone to test 2.6.37, doing a
confusion between 2.4.37 and 2.6.27. I have already tagged kernels
with wrong versions, having to fix by hand afterwards. It's really
cumbersome some times.

I remember it became really boring in 2.1.X days when X got past 99.

IMHO, having a small number of small digits is the way to go. Using
1 or 2 digits for the major and 1 for the minor is fine. After 3.9, you
go to version 4.0. Anyway, there are so many changes between versions
these days that any new versions could justify a major change (eg:
check the size of the 2.6.27 patch).

With versions from 1.1 to 9.9, you can go as high as 88 versions,
which is about 22 years of development at current pace. After that,
we can simply turn to 10.0 and not break anything.

It's also easier for users. Check how many non-kernel techies around you
know all 3 digits of the version they use. It's easier to remember 4.3
than it is to remember 2.6.27.

If we can stick to something like this, we can easily use the 3rd number
for the stable release. We would then have MAJOR.MINOR.PATCHRELEASE and
keep extraversion for -rc etc... The syntax does not change, thus limiting
the breakage and the change in habits.

Regards,
Willy


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  8:16             ` Steven Noonan
  2008-10-17 17:46               ` Greg KH
  2008-10-18  1:20               ` david
@ 2008-10-18  8:32               ` Willy Tarreau
  2 siblings, 0 replies; 111+ messages in thread
From: Willy Tarreau @ 2008-10-18  8:32 UTC (permalink / raw)
  To: Steven Noonan; +Cc: Greg KH, Adrian Bunk, Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 01:16:38AM -0700, Steven Noonan wrote:
> I believe some of Adrian's concerns are valid. Userspace programs will
> indeed break, largely because some depend on build-time and run-time
> checks for the kernel version being >=2.6.0 or >=2.4.0 and so forth. I
> suspect the best way to prove userspace breakage would be to make a
> branch of the kernel with a new versioning scheme (8.10, 2008.10,
> whatever) and use that as the installed kernel while building a Gentoo
> system. I suspect you'd see massive breakage.

The breakage is expected of course but should remain minor. It has
always existed, when switching from 2.0 to 2.1, then 2.1 to 2.2,
assuming that 2.2 was equivalent to 2.1.XX for some tools (remember
knfsd ?), then from 2.2 to 2.3, then to assume that 2.4 was roughly
equal to some 2.3.XX for some tools, then 2.5.XX then 2.6. Now some
tools know that all 2.6 are not equivalent and they add new checks
as versions appear.

It will not be a problem. Some versions of some tools will certainly
break at some point, but these are the ones used to check for a given
platform, and it is normal for them to evolve and follow new releases.

I know I have some build scripts packaging one way for 2.4 and another
way for 2.6. Should initramfs not work anymore for instance, I'd have
to rethink the process for more recent 2.6 anyway. It is possible that
I'll have to do this with the recent firmware changes.

Some tools which already assume that all 2.6 are equivalent will one
day or another have to refine their checks after kernel feature
removals which we're not allowed to complain about (eg: some modules).

So updating tools to add support for new versions is not a major problem
because it will eventually happen anyway.

> I think a version numbering system change would be OK (though I
> wouldn't very much -like- it), so long as there was a way for
> userspace software to be able to differentiate between a kernel with
> the old versioning system and the new versioning system.
> 
> I think perhaps a better option in the long run is to start a v2.7
> tree and figure out some Cool New Stuff(tm) to implement, keeping
> consistency with the current versioning scheme.

It would require tools updates as well.

Willy


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 17:42                 ` Greg KH
@ 2008-10-18  7:18                   ` H. Peter Anvin
  2008-10-20  3:48                     ` Alexandre Oliva
  0 siblings, 1 reply; 111+ messages in thread
From: H. Peter Anvin @ 2008-10-18  7:18 UTC (permalink / raw)
  To: Greg KH; +Cc: Alan Cox, Adrian Bunk, Linus Torvalds, linux-kernel

Greg KH wrote:
>>
>> I think it's both visually cumbersome and has the problem that it is harder 
>> to predict future releases.  The first problem can be dealt with by simply 
>> subtracting 2000 from the year (Altera uses this scheme for their EDA 
>> tools, and I didn't realize it for quite a while because it looked so 
>> natural), but the second is still a problem.
> 
> What is the "problem" of predicting future releases?  What relies on the
> actual number being "correct" some random time in the future?
> 

We already have the 2.6.28-rc series; and we are already talking about 
2.6.29 features.

We *really* don't want 2008.3-rc4 to be followed by 2009.1-rc5.  That is 
the kind of stuff that make script makers want to strangle developers 
alive with their own intestines.

	-hpa

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 12:46 ` Giacomo A. Catenazzi
  2008-10-17 17:40   ` Greg KH
@ 2008-10-18  1:32   ` david
  1 sibling, 0 replies; 111+ messages in thread
From: david @ 2008-10-18  1:32 UTC (permalink / raw)
  To: Giacomo A. Catenazzi; +Cc: Greg KH, Linus Torvalds, linux-kernel

On Fri, 17 Oct 2008, Giacomo A. Catenazzi wrote:

> Greg KH wrote:
>> We number the kernel based on the year, and the numbers of releases we
>> have done this year:
>> 	YEAR.NUMBER.MINOR_RELEASE
>> 
>> For example, the first release in 2009 would be called:
>> 	2009.0.0
>> The second:
>> 	2009.1.0
>> 
>> If we want to be a bit more "non-zero-counting" friendly: we can start
>> at "1" for the number:
>> 	2009.1.0 for the first release
>> 	2009.2.0 for the second.
>> 
>> Then the stable releases can increment the minor number:
>> 	2009.1.1 for the first stable release
>> 	2009.1.2 for the second.
>> 	and so on.
>> 
>> Benefits of this is it more accuratly represents to people just how old
>> the kernel they are currently running is (2.6.9 would be have been
>> 2004.9.0 on this naming scheme.)
>> 
>> Yes, we can handle the major/minor macros in the kernel to provide a
>> compatible number so that automated scripts will not break, that's not a
>> big deal.
>> 
>> Any thoughts?
>
> What about:
> - rc releases: a 2009.5.0-rc4 become suddenly 2010.0.0-rc5 ?

three options

1. change it as you state based on it slipping

2. 2009.5.0-rc4 goes to 2009.5.0-rc5 in January and we just accept a minor 
'oops' on the version number

3. 2009.5.0-rc4 goes to 2009.5.0-rc5 in January becouse we base the number 
on when the merge window opened, not when it's released.

personally I think 3 is the clearest to explain to people, but I don't 
like 1 (it's not that bad, but it leaves a lot of mail in archives and bug 
reports listing the 2009.5.0 version number when no such version was ever 
released)

> - a stable version in January of a kernel released in December
>  still has the old year? (I hope yes, but it could confuse users.)

absolutly, the stable version is the Nth revision of the kernel that was 
released in December, it doesn't matter when the stable release happened 
(similar to the 2.6.16.X kernels that have been released)

> - when (if) we need a big innovative (or incompatible) kernel
>  change, how to mark old and new kernels?

they are marked in the release announcemnts, and code that cares can do 
'is version > 2009.5' logic.

this sort of test is done today by software so that they can enable better 
functionality on newer kernels, the size of the difference shouldn't 
matter.

David Lang


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 22:49                     ` Rafael J. Wysocki
@ 2008-10-18  1:23                       ` david
  2008-10-18 23:14                         ` Jiri Kosina
  0 siblings, 1 reply; 111+ messages in thread
From: david @ 2008-10-18  1:23 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Greg KH, Alan Cox, Steven Noonan, Adrian Bunk, Linus Torvalds,
	linux-kernel

On Sat, 18 Oct 2008, Rafael J. Wysocki wrote:

> On Friday, 17 of October 2008, Greg KH wrote:
>> On Fri, Oct 17, 2008 at 08:47:23PM +0100, Alan Cox wrote:
>>>> And that's my point here, do we want to change the current numbering
>>>> scheme as people have expressed annoyances of the current one.
>>>
>>> But any new scheme will be just as annoying to someone and it messes up
>>> existing documentation, understanding and risks breaking third party
>>> tools.
>>>
>>> Is it really worth the hassle, plus we'll have to change again if we use
>>> date/times because once we are shipping Linux out to Alpha Centauri with
>>> colonists there will be serious problems trying to compute the effect of
>>> tau on release numbering ...
>>
>> Sure, but by then, the 2.6.521 release will be out and we could fix it
>> up by finally going to 3.0 :)
>
> Surely some scripts will start to break as soon as the third number gets
> three digits.

we've had three digit numbers in the third position before (2.3 and 2.5 
went well past three digits IIRC)

>> Seriously, am I the only one that is getting annoyed by our version
>> numbers?  If so, I can live with it, but I got the feeling that I wasn't
>> alone here.
>
> Actually, I thought we could continue to use a w.x.y.z numbering scheme, but
> in such a way that:
>
> w = ($year - 2000) / 10 + 2 (so that we start from 2)
> x = $year % 10
> y = (number of major release in $year)
> z = (number of stable version for major release w.x.y)
>
> Then, the first major release in 2009 would be 2.9.1 and its first -stable
> "child" would become 2.9.1.1.  In turn, the first major release in 2010 could
> be 3.0.1 and so on.

if you want the part of the version number to increment based on the year, 
just make it the year and don't complicate things.

David Lang

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  8:16             ` Steven Noonan
  2008-10-17 17:46               ` Greg KH
@ 2008-10-18  1:20               ` david
  2008-10-18  8:32               ` Willy Tarreau
  2 siblings, 0 replies; 111+ messages in thread
From: david @ 2008-10-18  1:20 UTC (permalink / raw)
  To: Steven Noonan; +Cc: Greg KH, Adrian Bunk, Linus Torvalds, linux-kernel

On Fri, 17 Oct 2008, Steven Noonan wrote:
> I believe some of Adrian's concerns are valid. Userspace programs will
> indeed break, largely because some depend on build-time and run-time
> checks for the kernel version being >=2.6.0 or >=2.4.0 and so forth.

things that do this sort of check would work just find with version 8.10.0 
or 2008.10.0

the ones that would fail would be ones that made assumptions about the 
number (it can only have X digits in this position, I don't need to check 
the '2', only the '4' vs '6', etc). anything that does this sort of thing 
is broken already, and will fail at some point in the future, even without 
a radical numbering change.

> I
> suspect the best way to prove userspace breakage would be to make a
> branch of the kernel with a new versioning scheme (8.10, 2008.10,
> whatever) and use that as the installed kernel while building a Gentoo
> system. I suspect you'd see massive breakage.

I suspect that you won't see anything noticable. you don't need to make a 
branch of the kernel, just edit the kernel source to change the version.

> I think a version numbering system change would be OK (though I
> wouldn't very much -like- it), so long as there was a way for
> userspace software to be able to differentiate between a kernel with
> the old versioning system and the new versioning system.

one nice thing about the year-based numbering (be it 8.x or 2008.x) is 
that all the numbers in the new numbering scheme are > any numbers in the 
old numbering scheme. so all you need to do is to check for > whatever 
version added the feature you need.

> I think perhaps a better option in the long run is to start a v2.7
> tree and figure out some Cool New Stuff(tm) to implement, keeping
> consistency with the current versioning scheme.

Red Herring, the Cool New Stuff is happening now, no 2.7 needed.

David Lang

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 21:44                   ` Greg KH
  2008-10-17 22:14                     ` Matthias Schniedermeyer
@ 2008-10-17 22:49                     ` Rafael J. Wysocki
  2008-10-18  1:23                       ` david
  2008-10-18  8:45                     ` Willy Tarreau
                                       ` (2 subsequent siblings)
  4 siblings, 1 reply; 111+ messages in thread
From: Rafael J. Wysocki @ 2008-10-17 22:49 UTC (permalink / raw)
  To: Greg KH
  Cc: Alan Cox, Steven Noonan, Adrian Bunk, Linus Torvalds, linux-kernel

On Friday, 17 of October 2008, Greg KH wrote:
> On Fri, Oct 17, 2008 at 08:47:23PM +0100, Alan Cox wrote:
> > > And that's my point here, do we want to change the current numbering
> > > scheme as people have expressed annoyances of the current one.
> > 
> > But any new scheme will be just as annoying to someone and it messes up
> > existing documentation, understanding and risks breaking third party
> > tools.
> > 
> > Is it really worth the hassle, plus we'll have to change again if we use
> > date/times because once we are shipping Linux out to Alpha Centauri with
> > colonists there will be serious problems trying to compute the effect of
> > tau on release numbering ...
> 
> Sure, but by then, the 2.6.521 release will be out and we could fix it
> up by finally going to 3.0 :)

Surely some scripts will start to break as soon as the third number gets
three digits.

> Seriously, am I the only one that is getting annoyed by our version
> numbers?  If so, I can live with it, but I got the feeling that I wasn't
> alone here.

Actually, I thought we could continue to use a w.x.y.z numbering scheme, but
in such a way that:

w = ($year - 2000) / 10 + 2 (so that we start from 2)
x = $year % 10
y = (number of major release in $year)
z = (number of stable version for major release w.x.y)

Then, the first major release in 2009 would be 2.9.1 and its first -stable
"child" would become 2.9.1.1.  In turn, the first major release in 2010 could
be 3.0.1 and so on.

This seems to be close enough to the current numbering so that nothing should
really break.

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 21:44                   ` Greg KH
@ 2008-10-17 22:14                     ` Matthias Schniedermeyer
  2008-10-17 22:49                     ` Rafael J. Wysocki
                                       ` (3 subsequent siblings)
  4 siblings, 0 replies; 111+ messages in thread
From: Matthias Schniedermeyer @ 2008-10-17 22:14 UTC (permalink / raw)
  To: Greg KH
  Cc: Alan Cox, Steven Noonan, Adrian Bunk, Linus Torvalds, linux-kernel

On 17.10.2008 14:44, Greg KH wrote:
> On Fri, Oct 17, 2008 at 08:47:23PM +0100, Alan Cox wrote:
> > > And that's my point here, do we want to change the current numbering
> > > scheme as people have expressed annoyances of the current one.
> > 
> > But any new scheme will be just as annoying to someone and it messes up
> > existing documentation, understanding and risks breaking third party
> > tools.
> > 
> > Is it really worth the hassle, plus we'll have to change again if we use
> > date/times because once we are shipping Linux out to Alpha Centauri with
> > colonists there will be serious problems trying to compute the effect of
> > tau on release numbering ...
> 
> Sure, but by then, the 2.6.521 release will be out and we could fix it
> up by finally going to 3.0 :)
> 
> Seriously, am I the only one that is getting annoyed by our version
> numbers?  If so, I can live with it, but I got the feeling that I wasn't
> alone here.

Personally i could live without the 4 part numbers of the stable series.

When you bump down the third position to second, then fill the third one 
with a dummy/fixed for the "Linus" release, the way is free for stable 
releases that don't feel so stapled to the side.

So with either .0 or .1 for the "Linus" release the next kernel could be:
2.8.0 or 2.8.1
(I would skip 2.7, because it is still perceived as the next development 
Version.)

The stable releases then increment the third number and the next Linus 
release could be 2.9.x because i don't think after 2.8 any skipping of 
uneven numbers would be needed anymore.

In Short: "Back to the roots" with a "good old" 3 part version numbers, 
with stable releases "build into the numbering scheme" instead of 
stapled to the side.




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.


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 19:06                 ` Bartlomiej Zolnierkiewicz
@ 2008-10-17 21:44                   ` Greg KH
  0 siblings, 0 replies; 111+ messages in thread
From: Greg KH @ 2008-10-17 21:44 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz
  Cc: Steven Noonan, Adrian Bunk, Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 09:06:28PM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Friday 17 October 2008, Greg KH wrote:
> > On Fri, Oct 17, 2008 at 01:16:38AM -0700, Steven Noonan wrote:
> > > I believe some of Adrian's concerns are valid. Userspace programs will
> > > indeed break, largely because some depend on build-time and run-time
> > > checks for the kernel version being >=2.6.0 or >=2.4.0 and so forth. I
> > > suspect the best way to prove userspace breakage would be to make a
> > > branch of the kernel with a new versioning scheme (8.10, 2008.10,
> > > whatever) and use that as the installed kernel while building a Gentoo
> > > system. I suspect you'd see massive breakage.
> > 
> > That would be trivial for me to test, IFF we want to do something like
> > this.
> > 
> > But again, that's a technical thing, that can be solved _IFF_ we want to
> > change things.
> > 
> > And that's my point here, do we want to change the current numbering
> > scheme as people have expressed annoyances of the current one.
> 
> Numbering scheme?  I thought we should all be using the official
> kernel version NAME after the -final release?  Was I mistaken?
> 
> PS1 seems like somebody forgot to update it for 2.6.27...

Cool, that means I get to do it :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 19:47                 ` Alan Cox
@ 2008-10-17 21:44                   ` Greg KH
  2008-10-17 22:14                     ` Matthias Schniedermeyer
                                       ` (4 more replies)
  0 siblings, 5 replies; 111+ messages in thread
From: Greg KH @ 2008-10-17 21:44 UTC (permalink / raw)
  To: Alan Cox; +Cc: Steven Noonan, Adrian Bunk, Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 08:47:23PM +0100, Alan Cox wrote:
> > And that's my point here, do we want to change the current numbering
> > scheme as people have expressed annoyances of the current one.
> 
> But any new scheme will be just as annoying to someone and it messes up
> existing documentation, understanding and risks breaking third party
> tools.
> 
> Is it really worth the hassle, plus we'll have to change again if we use
> date/times because once we are shipping Linux out to Alpha Centauri with
> colonists there will be serious problems trying to compute the effect of
> tau on release numbering ...

Sure, but by then, the 2.6.521 release will be out and we could fix it
up by finally going to 3.0 :)

Seriously, am I the only one that is getting annoyed by our version
numbers?  If so, I can live with it, but I got the feeling that I wasn't
alone here.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 19:45                 ` Alan Cox
@ 2008-10-17 21:42                   ` Greg KH
  0 siblings, 0 replies; 111+ messages in thread
From: Greg KH @ 2008-10-17 21:42 UTC (permalink / raw)
  To: Alan Cox; +Cc: Adrian Bunk, Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 08:45:06PM +0100, Alan Cox wrote:
> On Fri, 17 Oct 2008 10:41:27 -0700
> Greg KH <greg@kroah.com> wrote:
> 
> > On Fri, Oct 17, 2008 at 10:31:38AM +0100, Alan Cox wrote:
> > > > So I proposed an alternative, YEAR.NUMBER.  The year is easy to keep
> > > 
> > > Which calendaring system ?
> > 
> > I'm almost afraid to ask, but "which one would you prefer"? :)
> 
> The standard one shipped and supported by util-linux for the past 15 or
> more years
> 
> $ ddate
> Today is Setting Orange, the 71st day of Bureaucracy in the YOLD 3174

Fine with me :)

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 17:46               ` Greg KH
  2008-10-17 19:06                 ` Bartlomiej Zolnierkiewicz
@ 2008-10-17 19:47                 ` Alan Cox
  2008-10-17 21:44                   ` Greg KH
  1 sibling, 1 reply; 111+ messages in thread
From: Alan Cox @ 2008-10-17 19:47 UTC (permalink / raw)
  To: Greg KH; +Cc: Steven Noonan, Adrian Bunk, Linus Torvalds, linux-kernel

> And that's my point here, do we want to change the current numbering
> scheme as people have expressed annoyances of the current one.

But any new scheme will be just as annoying to someone and it messes up
existing documentation, understanding and risks breaking third party
tools.

Is it really worth the hassle, plus we'll have to change again if we use
date/times because once we are shipping Linux out to Alpha Centauri with
colonists there will be serious problems trying to compute the effect of
tau on release numbering ...

(Ducks)

Alan

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 17:41               ` Greg KH
@ 2008-10-17 19:45                 ` Alan Cox
  2008-10-17 21:42                   ` Greg KH
  0 siblings, 1 reply; 111+ messages in thread
From: Alan Cox @ 2008-10-17 19:45 UTC (permalink / raw)
  To: Greg KH; +Cc: Adrian Bunk, Linus Torvalds, linux-kernel

On Fri, 17 Oct 2008 10:41:27 -0700
Greg KH <greg@kroah.com> wrote:

> On Fri, Oct 17, 2008 at 10:31:38AM +0100, Alan Cox wrote:
> > > So I proposed an alternative, YEAR.NUMBER.  The year is easy to keep
> > 
> > Which calendaring system ?
> 
> I'm almost afraid to ask, but "which one would you prefer"? :)

The standard one shipped and supported by util-linux for the past 15 or
more years

$ ddate
Today is Setting Orange, the 71st day of Bureaucracy in the YOLD 3174


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 17:46               ` Greg KH
@ 2008-10-17 19:06                 ` Bartlomiej Zolnierkiewicz
  2008-10-17 21:44                   ` Greg KH
  2008-10-17 19:47                 ` Alan Cox
  1 sibling, 1 reply; 111+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2008-10-17 19:06 UTC (permalink / raw)
  To: Greg KH; +Cc: Steven Noonan, Adrian Bunk, Linus Torvalds, linux-kernel

On Friday 17 October 2008, Greg KH wrote:
> On Fri, Oct 17, 2008 at 01:16:38AM -0700, Steven Noonan wrote:
> > I believe some of Adrian's concerns are valid. Userspace programs will
> > indeed break, largely because some depend on build-time and run-time
> > checks for the kernel version being >=2.6.0 or >=2.4.0 and so forth. I
> > suspect the best way to prove userspace breakage would be to make a
> > branch of the kernel with a new versioning scheme (8.10, 2008.10,
> > whatever) and use that as the installed kernel while building a Gentoo
> > system. I suspect you'd see massive breakage.
> 
> That would be trivial for me to test, IFF we want to do something like
> this.
> 
> But again, that's a technical thing, that can be solved _IFF_ we want to
> change things.
> 
> And that's my point here, do we want to change the current numbering
> scheme as people have expressed annoyances of the current one.

Numbering scheme?  I thought we should all be using the official
kernel version NAME after the -final release?  Was I mistaken?

PS1 seems like somebody forgot to update it for 2.6.27...

PS2 current numbering scheme is OK

Thanks,
Bart

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  8:16             ` Steven Noonan
@ 2008-10-17 17:46               ` Greg KH
  2008-10-17 19:06                 ` Bartlomiej Zolnierkiewicz
  2008-10-17 19:47                 ` Alan Cox
  2008-10-18  1:20               ` david
  2008-10-18  8:32               ` Willy Tarreau
  2 siblings, 2 replies; 111+ messages in thread
From: Greg KH @ 2008-10-17 17:46 UTC (permalink / raw)
  To: Steven Noonan; +Cc: Adrian Bunk, Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 01:16:38AM -0700, Steven Noonan wrote:
> I believe some of Adrian's concerns are valid. Userspace programs will
> indeed break, largely because some depend on build-time and run-time
> checks for the kernel version being >=2.6.0 or >=2.4.0 and so forth. I
> suspect the best way to prove userspace breakage would be to make a
> branch of the kernel with a new versioning scheme (8.10, 2008.10,
> whatever) and use that as the installed kernel while building a Gentoo
> system. I suspect you'd see massive breakage.

That would be trivial for me to test, IFF we want to do something like
this.

But again, that's a technical thing, that can be solved _IFF_ we want to
change things.

And that's my point here, do we want to change the current numbering
scheme as people have expressed annoyances of the current one.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  8:56             ` Adrian Bunk
  2008-10-17 10:06               ` Peter Zijlstra
  2008-10-17 15:30               ` Chris Friesen
@ 2008-10-17 17:45               ` Greg KH
  2008-10-18  9:01               ` Willy Tarreau
  3 siblings, 0 replies; 111+ messages in thread
From: Greg KH @ 2008-10-17 17:45 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 11:56:04AM +0300, Adrian Bunk wrote:
> On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
> > On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
> >...
> > > Packages are built in a chroot with the correct release installed.
> > 
> > Then why would this break if they are being built against the correct,
> > older, kernel?
> 
> How could you build userspace "against a kernel"?
> 
> sys_*uname() returns the version of the running kernel.

Great, then why does the build system depend on the running kernel?
Doesn't that sound like a bug?

> > > > and that build would be
> > > > determining things based on the system it is built on, not what it is
> > > > being built for?
> > > 
> > > No.
> > > 
> > > In the example I gave it is OpenSSL that parses the version number of 
> > > the kernel.
> > 
> > The running kernel, with the expectation that this is the kernel it is
> > going to be running on after it is built, right?  Sounds like to ensure
> > this is correct, you better be building it on the kernel that you are
> > going to run it on, or its build process is broken.
> 
> I'm not even sure whether OpenSSL actually does anything with the 
> information: The script comes from the Apache foundation and
> claims to be "Similar to config.guess but much, much smaller."
> 
> BTW: Apache 1.3 seems to ship and use the same script.

Again, depending on the kernel the product is being built on, to
determine a build-time configuration, seems quite broken if you want to
do cross-compilation.

Or you just do native builds, on the kernel you expect to run the
product, and everyone is happy and there are no errors.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 16:40               ` H. Peter Anvin
@ 2008-10-17 17:42                 ` Greg KH
  2008-10-18  7:18                   ` H. Peter Anvin
  0 siblings, 1 reply; 111+ messages in thread
From: Greg KH @ 2008-10-17 17:42 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Alan Cox, Adrian Bunk, Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 09:40:32AM -0700, H. Peter Anvin wrote:
> Alan Cox wrote:
>>> So I proposed an alternative, YEAR.NUMBER.  The year is easy to keep
>> Which calendaring system ?
>
> Presumably the Gregorian one, rooted in the Common Era, but that's sort of 
> irrelevant.
>
> I think it's both visually cumbersome and has the problem that it is harder 
> to predict future releases.  The first problem can be dealt with by simply 
> subtracting 2000 from the year (Altera uses this scheme for their EDA 
> tools, and I didn't realize it for quite a while because it looked so 
> natural), but the second is still a problem.

What is the "problem" of predicting future releases?  What relies on the
actual number being "correct" some random time in the future?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  9:31             ` Alan Cox
  2008-10-17 16:40               ` H. Peter Anvin
@ 2008-10-17 17:41               ` Greg KH
  2008-10-17 19:45                 ` Alan Cox
  1 sibling, 1 reply; 111+ messages in thread
From: Greg KH @ 2008-10-17 17:41 UTC (permalink / raw)
  To: Alan Cox; +Cc: Adrian Bunk, Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 10:31:38AM +0100, Alan Cox wrote:
> > So I proposed an alternative, YEAR.NUMBER.  The year is easy to keep
> 
> Which calendaring system ?

I'm almost afraid to ask, but "which one would you prefer"? :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 12:46 ` Giacomo A. Catenazzi
@ 2008-10-17 17:40   ` Greg KH
  2008-10-18  1:32   ` david
  1 sibling, 0 replies; 111+ messages in thread
From: Greg KH @ 2008-10-17 17:40 UTC (permalink / raw)
  To: Giacomo A. Catenazzi; +Cc: Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 02:46:27PM +0200, Giacomo A. Catenazzi wrote:
> Greg KH wrote:
>> We number the kernel based on the year, and the numbers of releases we
>> have done this year:
>> 	YEAR.NUMBER.MINOR_RELEASE
>> For example, the first release in 2009 would be called:
>> 	2009.0.0
>> The second:
>> 	2009.1.0
>> If we want to be a bit more "non-zero-counting" friendly: we can start
>> at "1" for the number:
>> 	2009.1.0 for the first release
>> 	2009.2.0 for the second.
>> Then the stable releases can increment the minor number:
>> 	2009.1.1 for the first stable release
>> 	2009.1.2 for the second.
>> 	and so on.
>> Benefits of this is it more accuratly represents to people just how old
>> the kernel they are currently running is (2.6.9 would be have been
>> 2004.9.0 on this naming scheme.)
>> Yes, we can handle the major/minor macros in the kernel to provide a
>> compatible number so that automated scripts will not break, that's not a
>> big deal.
>> Any thoughts?
>
> What about:
> - rc releases: a 2009.5.0-rc4 become suddenly 2010.0.0-rc5 ?

Sure, what's the big deal?

> - a stable version in January of a kernel released in December
>   still has the old year? (I hope yes, but it could confuse users.)

stable versions would not modify the year.

> - when (if) we need a big innovative (or incompatible) kernel
>   change, how to mark old and new kernels?

Based on our current development model, this isn't an issue.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  9:31             ` Alan Cox
@ 2008-10-17 16:40               ` H. Peter Anvin
  2008-10-17 17:42                 ` Greg KH
  2008-10-17 17:41               ` Greg KH
  1 sibling, 1 reply; 111+ messages in thread
From: H. Peter Anvin @ 2008-10-17 16:40 UTC (permalink / raw)
  To: Alan Cox; +Cc: Greg KH, Adrian Bunk, Linus Torvalds, linux-kernel

Alan Cox wrote:
>> So I proposed an alternative, YEAR.NUMBER.  The year is easy to keep
> 
> Which calendaring system ?

Presumably the Gregorian one, rooted in the Common Era, but that's sort 
of irrelevant.

I think it's both visually cumbersome and has the problem that it is 
harder to predict future releases.  The first problem can be dealt with 
by simply subtracting 2000 from the year (Altera uses this scheme for 
their EDA tools, and I didn't realize it for quite a while because it 
looked so natural), but the second is still a problem.

	-hpa

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  8:56             ` Adrian Bunk
  2008-10-17 10:06               ` Peter Zijlstra
@ 2008-10-17 15:30               ` Chris Friesen
  2008-10-17 17:45               ` Greg KH
  2008-10-18  9:01               ` Willy Tarreau
  3 siblings, 0 replies; 111+ messages in thread
From: Chris Friesen @ 2008-10-17 15:30 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Greg KH, Linus Torvalds, linux-kernel

Adrian Bunk wrote:
> On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
>> On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
>> ...
>>> Packages are built in a chroot with the correct release installed.
>> Then why would this break if they are being built against the correct,
>> older, kernel?
> 
> How could you build userspace "against a kernel"?

I imagine many embedded products regularly build (or even cross-build) a 
kernel and a matching userspace against that kernel, independent of the 
running kernel on the build machine.  I know that we do it every day...

Chris

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  0:25 Greg KH
                   ` (7 preceding siblings ...)
  2008-10-17  1:26 ` Rob Landley
@ 2008-10-17 12:46 ` Giacomo A. Catenazzi
  2008-10-17 17:40   ` Greg KH
  2008-10-18  1:32   ` david
  8 siblings, 2 replies; 111+ messages in thread
From: Giacomo A. Catenazzi @ 2008-10-17 12:46 UTC (permalink / raw)
  To: Greg KH; +Cc: Linus Torvalds, linux-kernel

Greg KH wrote:
> We number the kernel based on the year, and the numbers of releases we
> have done this year:
> 	YEAR.NUMBER.MINOR_RELEASE
> 
> For example, the first release in 2009 would be called:
> 	2009.0.0
> The second:
> 	2009.1.0
> 
> If we want to be a bit more "non-zero-counting" friendly: we can start
> at "1" for the number:
> 	2009.1.0 for the first release
> 	2009.2.0 for the second.
> 
> Then the stable releases can increment the minor number:
> 	2009.1.1 for the first stable release
> 	2009.1.2 for the second.
> 	and so on.
> 
> Benefits of this is it more accuratly represents to people just how old
> the kernel they are currently running is (2.6.9 would be have been
> 2004.9.0 on this naming scheme.)
> 
> Yes, we can handle the major/minor macros in the kernel to provide a
> compatible number so that automated scripts will not break, that's not a
> big deal.
> 
> Any thoughts?

What about:
- rc releases: a 2009.5.0-rc4 become suddenly 2010.0.0-rc5 ?
- a stable version in January of a kernel released in December
   still has the old year? (I hope yes, but it could confuse users.)
- when (if) we need a big innovative (or incompatible) kernel
   change, how to mark old and new kernels?

ciao
	cate

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 11:26                   ` Peter Zijlstra
@ 2008-10-17 11:32                     ` Alexey Dobriyan
  0 siblings, 0 replies; 111+ messages in thread
From: Alexey Dobriyan @ 2008-10-17 11:32 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Adrian Bunk, Greg KH, Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 01:26:27PM +0200, Peter Zijlstra wrote:
> On Fri, 2008-10-17 at 15:18 +0400, Alexey Dobriyan wrote:
> > On Fri, Oct 17, 2008 at 12:06:30PM +0200, Peter Zijlstra wrote:
> > > On Fri, 2008-10-17 at 11:56 +0300, Adrian Bunk wrote:
> > > > On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
> > > > > On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
> > > > >...
> > > > > > Packages are built in a chroot with the correct release installed.
> > > > > 
> > > > > Then why would this break if they are being built against the correct,
> > > > > older, kernel?
> > > > 
> > > > How could you build userspace "against a kernel"?
> > > > 
> > > > sys_*uname() returns the version of the running kernel.
> > > 
> > > We have a uts namespace, you can make the thing return whatever well you
> > > please.
> > 
> > Hostname, domainname, what else?
> 
> Can't it fake the version number? - 

It can, but is there a system call for this?

> sounds like a useful feature :-)

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 11:18                 ` Alexey Dobriyan
@ 2008-10-17 11:26                   ` Peter Zijlstra
  2008-10-17 11:32                     ` Alexey Dobriyan
  0 siblings, 1 reply; 111+ messages in thread
From: Peter Zijlstra @ 2008-10-17 11:26 UTC (permalink / raw)
  To: Alexey Dobriyan; +Cc: Adrian Bunk, Greg KH, Linus Torvalds, linux-kernel

On Fri, 2008-10-17 at 15:18 +0400, Alexey Dobriyan wrote:
> On Fri, Oct 17, 2008 at 12:06:30PM +0200, Peter Zijlstra wrote:
> > On Fri, 2008-10-17 at 11:56 +0300, Adrian Bunk wrote:
> > > On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
> > > > On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
> > > >...
> > > > > Packages are built in a chroot with the correct release installed.
> > > > 
> > > > Then why would this break if they are being built against the correct,
> > > > older, kernel?
> > > 
> > > How could you build userspace "against a kernel"?
> > > 
> > > sys_*uname() returns the version of the running kernel.
> > 
> > We have a uts namespace, you can make the thing return whatever well you
> > please.
> 
> Hostname, domainname, what else?

Can't it fake the version number? - sounds like a useful feature :-)


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17 10:06               ` Peter Zijlstra
@ 2008-10-17 11:18                 ` Alexey Dobriyan
  2008-10-17 11:26                   ` Peter Zijlstra
  0 siblings, 1 reply; 111+ messages in thread
From: Alexey Dobriyan @ 2008-10-17 11:18 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Adrian Bunk, Greg KH, Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 12:06:30PM +0200, Peter Zijlstra wrote:
> On Fri, 2008-10-17 at 11:56 +0300, Adrian Bunk wrote:
> > On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
> > > On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
> > >...
> > > > Packages are built in a chroot with the correct release installed.
> > > 
> > > Then why would this break if they are being built against the correct,
> > > older, kernel?
> > 
> > How could you build userspace "against a kernel"?
> > 
> > sys_*uname() returns the version of the running kernel.
> 
> We have a uts namespace, you can make the thing return whatever well you
> please.

Hostname, domainname, what else?

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  8:56             ` Adrian Bunk
@ 2008-10-17 10:06               ` Peter Zijlstra
  2008-10-17 11:18                 ` Alexey Dobriyan
  2008-10-17 15:30               ` Chris Friesen
                                 ` (2 subsequent siblings)
  3 siblings, 1 reply; 111+ messages in thread
From: Peter Zijlstra @ 2008-10-17 10:06 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Greg KH, Linus Torvalds, linux-kernel

On Fri, 2008-10-17 at 11:56 +0300, Adrian Bunk wrote:
> On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
> > On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
> >...
> > > Packages are built in a chroot with the correct release installed.
> > 
> > Then why would this break if they are being built against the correct,
> > older, kernel?
> 
> How could you build userspace "against a kernel"?
> 
> sys_*uname() returns the version of the running kernel.

We have a uts namespace, you can make the thing return whatever well you
please.




^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  4:02           ` Greg KH
  2008-10-17  4:26             ` Grant Coady
  2008-10-17  4:53             ` Randy Dunlap
@ 2008-10-17  9:31             ` Alan Cox
  2008-10-17 16:40               ` H. Peter Anvin
  2008-10-17 17:41               ` Greg KH
  2 siblings, 2 replies; 111+ messages in thread
From: Alan Cox @ 2008-10-17  9:31 UTC (permalink / raw)
  To: Greg KH; +Cc: Adrian Bunk, Linus Torvalds, linux-kernel

> So I proposed an alternative, YEAR.NUMBER.  The year is easy to keep

Which calendaring system ?

Alan

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  9:05       ` Jike Song
@ 2008-10-17  9:14         ` Dave Young
  0 siblings, 0 replies; 111+ messages in thread
From: Dave Young @ 2008-10-17  9:14 UTC (permalink / raw)
  To: Jike Song; +Cc: Theodore Tso, linux-kernel

On Fri, Oct 17, 2008 at 5:05 PM, Jike Song <albcamus@gmail.com> wrote:
> On Fri, Oct 17, 2008 at 9:53 AM, Dave Young <hidave.darkstar@gmail.com> wrote:
>>
>> Additionally, we can add some range to x.y.z
>>
>> such as:
>>
>> x: 1-9
>> y: 1-9
>> z: 1-30
>>
>> so we can jumo to 2.7.1 after 2.6.30
>>
>
> Then people will think 2.7.x is a development version like 2.5.x ...

But it isn't. I think it doesn't matter.

There's no such development version now. It's just a chance to let
every one know the old change.

-- 
Regards
dave

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  1:53     ` Dave Young
@ 2008-10-17  9:05       ` Jike Song
  2008-10-17  9:14         ` Dave Young
  0 siblings, 1 reply; 111+ messages in thread
From: Jike Song @ 2008-10-17  9:05 UTC (permalink / raw)
  To: Dave Young; +Cc: Theodore Tso, linux-kernel

On Fri, Oct 17, 2008 at 9:53 AM, Dave Young <hidave.darkstar@gmail.com> wrote:
>
> Additionally, we can add some range to x.y.z
>
> such as:
>
> x: 1-9
> y: 1-9
> z: 1-30
>
> so we can jumo to 2.7.1 after 2.6.30
>

Then people will think 2.7.x is a development version like 2.5.x ...

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  7:55           ` Greg KH
  2008-10-17  8:16             ` Steven Noonan
@ 2008-10-17  8:56             ` Adrian Bunk
  2008-10-17 10:06               ` Peter Zijlstra
                                 ` (3 more replies)
  1 sibling, 4 replies; 111+ messages in thread
From: Adrian Bunk @ 2008-10-17  8:56 UTC (permalink / raw)
  To: Greg KH; +Cc: Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 12:55:44AM -0700, Greg KH wrote:
> On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
>...
> > Packages are built in a chroot with the correct release installed.
> 
> Then why would this break if they are being built against the correct,
> older, kernel?

How could you build userspace "against a kernel"?

sys_*uname() returns the version of the running kernel.

> > > and that build would be
> > > determining things based on the system it is built on, not what it is
> > > being built for?
> > 
> > No.
> > 
> > In the example I gave it is OpenSSL that parses the version number of 
> > the kernel.
> 
> The running kernel, with the expectation that this is the kernel it is
> going to be running on after it is built, right?  Sounds like to ensure
> this is correct, you better be building it on the kernel that you are
> going to run it on, or its build process is broken.

I'm not even sure whether OpenSSL actually does anything with the 
information: The script comes from the Apache foundation and
claims to be "Similar to config.guess but much, much smaller."

BTW: Apache 1.3 seems to ship and use the same script.

>...
> > Building in a chroot is hardly "very broken".
> > 
> > And it does build against the correct
> > libraries/kernel headers/gcc/glibc/etc .
> 
> But not against the proper kernel it will be run on, which sounds
> broken.

Building software in a chroot is a common thing if you don't want to 
setup a dedicated machine for a build environment (and all these hyped 
virtualization solutions tend to not support architectures like alpha
or parisc).

>...
> > And this was just one example.
> > 
> > What does userspace with the kernel version returned by GDTIOCTL_OSVERS?
> 
> I don't know, hopefully not much if anything.  glibc does things with
> it, but that is usually to turn off emulation of various features that
> are in the kernel in newer releases.
> 
> > I don't know whether it just displays the number, or whether it 
> > determines anything based on it.
> > 
> > Or what else might parse the version number?
> > 
> > What if some proprietary userspace software like Skype or Flash or 
> > whatever parses the kernel version number at runtime and barfs on 
> > 2009.2.3 in a way similar to the OpenSSL build system?
> > 
> > WHAT YOU SUGGEST WILL BREAK EXISTING USERSPACE SOFTWARE.
> > 
> > Please admit this fact.
> 
> "Might" I will give you, "Will", I will not without actually testing.

The OpenSSL 0.9.8 config script is existing userspace, and it will 
break.

That is one example that "Will" definitely break (no matter how broken 
or how easy to fix it is).

> And hey, if it's a problem, just fix userspace reporting to always say
> we are the 2.6.30 release and go on our merry way, perhaps providing
> another sysctl if it's really needed (glibc probably wants it, so it
> would be easy to add.)
> 
> That's just a minor technical thing that can be trivially fixed _IF_ we
> decide it is something that we want to do.

If we do not continue to report the correct version in sys_*uname()
(and therefore in "uname -r") we break standard POSIX behavior.

The implementation might be trivial, but choosing between breaking 
existing userspace and breaking longexisting and standardized UNIX
behavior is not a nice choice.

> And to get back to the original point, Linus had expressed such an
> interest in changing this a while ago, so I was bringing it up, saying
> that I to thought we should change this, and proposed one such naming
> change.

Was he aware of the consequences?

>...
> thanks,
> 
> greg "take a chill pill" k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  7:55           ` Greg KH
@ 2008-10-17  8:16             ` Steven Noonan
  2008-10-17 17:46               ` Greg KH
                                 ` (2 more replies)
  2008-10-17  8:56             ` Adrian Bunk
  1 sibling, 3 replies; 111+ messages in thread
From: Steven Noonan @ 2008-10-17  8:16 UTC (permalink / raw)
  To: Greg KH; +Cc: Adrian Bunk, Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 12:55 AM, Greg KH <greg@kroah.com> wrote:
> On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
>> On Thu, Oct 16, 2008 at 08:47:17PM -0700, Greg KH wrote:
>> > On Thu, Oct 16, 2008 at 07:46:02PM +0300, Adrian Bunk wrote:
>> > > On Thu, Oct 16, 2008 at 08:17:48AM -0700, Greg KH wrote:
>> > > > On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
>> > > >...
>> > > > > If a distribution will try to autobuild an urgent OpenSSL security
>> > > > > update for their stable release in a chroot on a machine running
>> > > > > kernel 2009.2.3 they will surely love you for being responsible
>> > > > > for this...
>> > > >
>> > > > Distros properly patch things and backport "urgent OpenSSL security
>> > > > updates" to older versions of packages, so they would not run into this
>> > > > problem.
>> > >
>> > > You didn't get my point.
>> > >
>> > > Let me make an example:
>> > >
>> > > The current Debian release will be supported until one year after the
>> > > next release gets released.
>> > >
>> > > Someone from the Debian security team send a fixed package to the
>> > > buildds.
>> > >
>> > > The buildds build packages in chroots.
>> > >
>> > > A buildd may run any Debian release.
>> > >
>> > > And it's perfectly normal that a buildd runs a more recent release of
>> > > Debian than the one a package gets built for in a chroot.
>> >
>> > So you are saying the Debian build system would build a package for an
>> > older release, on a system that is newer,
>>
>> Packages are built in a chroot with the correct release installed.
>
> Then why would this break if they are being built against the correct,
> older, kernel?
>
>> > and that build would be
>> > determining things based on the system it is built on, not what it is
>> > being built for?
>>
>> No.
>>
>> In the example I gave it is OpenSSL that parses the version number of
>> the kernel.
>
> The running kernel, with the expectation that this is the kernel it is
> going to be running on after it is built, right?  Sounds like to ensure
> this is correct, you better be building it on the kernel that you are
> going to run it on, or its build process is broken.
>
>> > If so, then something is very broken already in the Debian build system
>> > and I think you have much bigger problems to worry about right now.
>> >
>> > For all other "sane" build systems that I know of, you build against the
>> > libraries/kernel/gcc/glibc/etc that you are wanting to support it for,
>> > not against some random-whatever-happened-to-be-installed-on-the-box.
>>
>> Building in a chroot is hardly "very broken".
>>
>> And it does build against the correct
>> libraries/kernel headers/gcc/glibc/etc .
>
> But not against the proper kernel it will be run on, which sounds
> broken.
>
>> Did you ever use a chroot?
>
> There's a fine line between being condencending and asking a valid
> question.  I'll assume you are not being condencending here...
>
> Yes, of course.
>
>> And this was just one example.
>>
>> What does userspace with the kernel version returned by GDTIOCTL_OSVERS?
>
> I don't know, hopefully not much if anything.  glibc does things with
> it, but that is usually to turn off emulation of various features that
> are in the kernel in newer releases.
>
>> I don't know whether it just displays the number, or whether it
>> determines anything based on it.
>>
>> Or what else might parse the version number?
>>
>> What if some proprietary userspace software like Skype or Flash or
>> whatever parses the kernel version number at runtime and barfs on
>> 2009.2.3 in a way similar to the OpenSSL build system?
>>
>> WHAT YOU SUGGEST WILL BREAK EXISTING USERSPACE SOFTWARE.
>>
>> Please admit this fact.
>
> "Might" I will give you, "Will", I will not without actually testing.
>
> And hey, if it's a problem, just fix userspace reporting to always say
> we are the 2.6.30 release and go on our merry way, perhaps providing
> another sysctl if it's really needed (glibc probably wants it, so it
> would be easy to add.)
>
> That's just a minor technical thing that can be trivially fixed _IF_ we
> decide it is something that we want to do.
>
> And to get back to the original point, Linus had expressed such an
> interest in changing this a while ago, so I was bringing it up, saying
> that I to thought we should change this, and proposed one such naming
> change.
>
> That has nothing to do with the "OMG You killed SKYPE!" hysteria that
> you are proposing here.  Please separate the two issues as they are
> totally different.
>
> thanks,
>
> greg "take a chill pill" k-h

I believe some of Adrian's concerns are valid. Userspace programs will
indeed break, largely because some depend on build-time and run-time
checks for the kernel version being >=2.6.0 or >=2.4.0 and so forth. I
suspect the best way to prove userspace breakage would be to make a
branch of the kernel with a new versioning scheme (8.10, 2008.10,
whatever) and use that as the installed kernel while building a Gentoo
system. I suspect you'd see massive breakage.

I think a version numbering system change would be OK (though I
wouldn't very much -like- it), so long as there was a way for
userspace software to be able to differentiate between a kernel with
the old versioning system and the new versioning system.

I think perhaps a better option in the long run is to start a v2.7
tree and figure out some Cool New Stuff(tm) to implement, keeping
consistency with the current versioning scheme.

- Steven

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  6:47         ` Adrian Bunk
@ 2008-10-17  7:55           ` Greg KH
  2008-10-17  8:16             ` Steven Noonan
  2008-10-17  8:56             ` Adrian Bunk
  0 siblings, 2 replies; 111+ messages in thread
From: Greg KH @ 2008-10-17  7:55 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Linus Torvalds, linux-kernel

On Fri, Oct 17, 2008 at 09:47:51AM +0300, Adrian Bunk wrote:
> On Thu, Oct 16, 2008 at 08:47:17PM -0700, Greg KH wrote:
> > On Thu, Oct 16, 2008 at 07:46:02PM +0300, Adrian Bunk wrote:
> > > On Thu, Oct 16, 2008 at 08:17:48AM -0700, Greg KH wrote:
> > > > On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
> > > >...
> > > > > If a distribution will try to autobuild an urgent OpenSSL security 
> > > > > update for their stable release in a chroot on a machine running
> > > > > kernel 2009.2.3 they will surely love you for being responsible
> > > > > for this...
> > > > 
> > > > Distros properly patch things and backport "urgent OpenSSL security
> > > > updates" to older versions of packages, so they would not run into this
> > > > problem.
> > > 
> > > You didn't get my point.
> > > 
> > > Let me make an example:
> > > 
> > > The current Debian release will be supported until one year after the
> > > next release gets released.
> > > 
> > > Someone from the Debian security team send a fixed package to the
> > > buildds.
> > > 
> > > The buildds build packages in chroots.
> > > 
> > > A buildd may run any Debian release.
> > > 
> > > And it's perfectly normal that a buildd runs a more recent release of 
> > > Debian than the one a package gets built for in a chroot.
> > 
> > So you are saying the Debian build system would build a package for an
> > older release, on a system that is newer,
> 
> Packages are built in a chroot with the correct release installed.

Then why would this break if they are being built against the correct,
older, kernel?

> > and that build would be
> > determining things based on the system it is built on, not what it is
> > being built for?
> 
> No.
> 
> In the example I gave it is OpenSSL that parses the version number of 
> the kernel.

The running kernel, with the expectation that this is the kernel it is
going to be running on after it is built, right?  Sounds like to ensure
this is correct, you better be building it on the kernel that you are
going to run it on, or its build process is broken.

> > If so, then something is very broken already in the Debian build system
> > and I think you have much bigger problems to worry about right now.
> > 
> > For all other "sane" build systems that I know of, you build against the
> > libraries/kernel/gcc/glibc/etc that you are wanting to support it for,
> > not against some random-whatever-happened-to-be-installed-on-the-box.
> 
> Building in a chroot is hardly "very broken".
> 
> And it does build against the correct
> libraries/kernel headers/gcc/glibc/etc .

But not against the proper kernel it will be run on, which sounds
broken.

> Did you ever use a chroot?

There's a fine line between being condencending and asking a valid
question.  I'll assume you are not being condencending here...

Yes, of course.

> And this was just one example.
> 
> What does userspace with the kernel version returned by GDTIOCTL_OSVERS?

I don't know, hopefully not much if anything.  glibc does things with
it, but that is usually to turn off emulation of various features that
are in the kernel in newer releases.

> I don't know whether it just displays the number, or whether it 
> determines anything based on it.
> 
> Or what else might parse the version number?
> 
> What if some proprietary userspace software like Skype or Flash or 
> whatever parses the kernel version number at runtime and barfs on 
> 2009.2.3 in a way similar to the OpenSSL build system?
> 
> WHAT YOU SUGGEST WILL BREAK EXISTING USERSPACE SOFTWARE.
> 
> Please admit this fact.

"Might" I will give you, "Will", I will not without actually testing.

And hey, if it's a problem, just fix userspace reporting to always say
we are the 2.6.30 release and go on our merry way, perhaps providing
another sysctl if it's really needed (glibc probably wants it, so it
would be easy to add.)

That's just a minor technical thing that can be trivially fixed _IF_ we
decide it is something that we want to do.

And to get back to the original point, Linus had expressed such an
interest in changing this a while ago, so I was bringing it up, saying
that I to thought we should change this, and proposed one such naming
change.

That has nothing to do with the "OMG You killed SKYPE!" hysteria that
you are proposing here.  Please separate the two issues as they are
totally different.

thanks,

greg "take a chill pill" k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  3:47       ` Greg KH
@ 2008-10-17  6:47         ` Adrian Bunk
  2008-10-17  7:55           ` Greg KH
  0 siblings, 1 reply; 111+ messages in thread
From: Adrian Bunk @ 2008-10-17  6:47 UTC (permalink / raw)
  To: Greg KH; +Cc: Linus Torvalds, linux-kernel

On Thu, Oct 16, 2008 at 08:47:17PM -0700, Greg KH wrote:
> On Thu, Oct 16, 2008 at 07:46:02PM +0300, Adrian Bunk wrote:
> > On Thu, Oct 16, 2008 at 08:17:48AM -0700, Greg KH wrote:
> > > On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
> > >...
> > > > If a distribution will try to autobuild an urgent OpenSSL security 
> > > > update for their stable release in a chroot on a machine running
> > > > kernel 2009.2.3 they will surely love you for being responsible
> > > > for this...
> > > 
> > > Distros properly patch things and backport "urgent OpenSSL security
> > > updates" to older versions of packages, so they would not run into this
> > > problem.
> > 
> > You didn't get my point.
> > 
> > Let me make an example:
> > 
> > The current Debian release will be supported until one year after the
> > next release gets released.
> > 
> > Someone from the Debian security team send a fixed package to the
> > buildds.
> > 
> > The buildds build packages in chroots.
> > 
> > A buildd may run any Debian release.
> > 
> > And it's perfectly normal that a buildd runs a more recent release of 
> > Debian than the one a package gets built for in a chroot.
> 
> So you are saying the Debian build system would build a package for an
> older release, on a system that is newer,

Packages are built in a chroot with the correct release installed.

> and that build would be
> determining things based on the system it is built on, not what it is
> being built for?

No.

In the example I gave it is OpenSSL that parses the version number of 
the kernel.

> If so, then something is very broken already in the Debian build system
> and I think you have much bigger problems to worry about right now.
> 
> For all other "sane" build systems that I know of, you build against the
> libraries/kernel/gcc/glibc/etc that you are wanting to support it for,
> not against some random-whatever-happened-to-be-installed-on-the-box.

Building in a chroot is hardly "very broken".

And it does build against the correct
libraries/kernel headers/gcc/glibc/etc .

Did you ever use a chroot?


And this was just one example.

What does userspace with the kernel version returned by GDTIOCTL_OSVERS?
I don't know whether it just displays the number, or whether it 
determines anything based on it.

Or what else might parse the version number?

What if some proprietary userspace software like Skype or Flash or 
whatever parses the kernel version number at runtime and barfs on 
2009.2.3 in a way similar to the OpenSSL build system?

WHAT YOU SUGGEST WILL BREAK EXISTING USERSPACE SOFTWARE.

Please admit this fact.


>...
> Hope this helps,
> 
> greg k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  4:02           ` Greg KH
  2008-10-17  4:26             ` Grant Coady
@ 2008-10-17  4:53             ` Randy Dunlap
  2008-10-17  9:31             ` Alan Cox
  2 siblings, 0 replies; 111+ messages in thread
From: Randy Dunlap @ 2008-10-17  4:53 UTC (permalink / raw)
  To: Greg KH; +Cc: Adrian Bunk, Linus Torvalds, linux-kernel

On Thu, 16 Oct 2008 21:02:39 -0700 Greg KH wrote:

> On Thu, Oct 16, 2008 at 08:16:26PM +0300, Adrian Bunk wrote:
> > On Thu, Oct 16, 2008 at 08:47:26AM -0700, Greg KH wrote:
> > You miss the best alternative:
> > 
> > Simply keep the status quo.
> 
> I'd argue that is is a pain.  Linus has expressed frustration with the
> current numbering scheme, and as someone who deals with kernel version
> numbers every single day, I too am mildly frustrated.
> 
> I think the main reason why is just that small numbers are easier to
> keep track of in your mind.  As we are ever increasing the version
> number, the release numbers feel like they are getting closer together,
> making them less distinguishable.
> 
> For example, think of the following:
> 	2.6.5 vs. 2.6.9
> Your mind focuses on the 5 and 9, and in thinking about them, it is much
> easier to keep them apart.
> 
> Now, try the same with:
> 	2.6.24 vs. 2.6.27
> You are repeating the tens digit, the "two", so it is a bit harder to
> distinguish things.  After a few years of this, it gets more difficult
> 
> So I proposed an alternative, YEAR.NUMBER.  The year is easy to keep
> track of, and the release number is a small one, making it too easier to
> track and distinguish from each other:
> 	2009.1 vs. 2009.5
> or
> 	2010.2 vs. 2011.5
> It also means something that lets you remember back to what was going on
> for that release better, if you can easily place it within a specific
> time frame, which is important for those of us who work with different
> kernel versions all the time for different projects and backports and
> stable releases.
> 
> If the number stays the same, my feeble brain will survive and I'll just
> rely on my huge spreadsheet of when specific kernels were released when
> to get along, and hopefully I will not make any more .26.5 releases when
> I mean .25.5 and such like I have in the past :)

Nah, that can/will still happen (for someone).

I still fail to see what is br0ken and needs to be fixed...

---
~Randy

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-17  4:02           ` Greg KH
@ 2008-10-17  4:26             ` Grant Coady
  2008-10-17  4:53             ` Randy Dunlap
  2008-10-17  9:31             ` Alan Cox
  2 siblings, 0 replies; 111+ messages in thread
From: Grant Coady @ 2008-10-17  4:26 UTC (permalink / raw)
  To: Greg KH; +Cc: Adrian Bunk, Linus Torvalds, linux-kernel

On Thu, 16 Oct 2008 21:02:39 -0700, you wrote:

>On Thu, Oct 16, 2008 at 08:16:26PM +0300, Adrian Bunk wrote:
>> On Thu, Oct 16, 2008 at 08:47:26AM -0700, Greg KH wrote:
>> You miss the best alternative:
>> 
>> Simply keep the status quo.
>
>I'd argue that is is a pain.  Linus has expressed frustration with the
>current numbering scheme, and as someone who deals with kernel version
>numbers every single day, I too am mildly frustrated.
>
>I think the main reason why is just that small numbers are easier to
>keep track of in your mind.  As we are ever increasing the version
>number, the release numbers feel like they are getting closer together,
>making them less distinguishable.
>
>For example, think of the following:
>	2.6.5 vs. 2.6.9
>Your mind focuses on the 5 and 9, and in thinking about them, it is much
>easier to keep them apart.
>
>Now, try the same with:
>	2.6.24 vs. 2.6.27
>You are repeating the tens digit, the "two", so it is a bit harder to
>distinguish things.  After a few years of this, it gets more difficult
>
>So I proposed an alternative, YEAR.NUMBER.  The year is easy to keep
>track of, and the release number is a small one, making it too easier to
>track and distinguish from each other:
>	2009.1 vs. 2009.5
>or
>	2010.2 vs. 2011.5

So add a 'RELEASEDATE = 2008-nn-nn' on line five of the top Makefile 
just under the 'NAME = Rotary Wombat' variation.

Perhaps lose the leading '2.6.' when 2.6.30 comes around, give some 
warning to all that their scripts are gonna break with that release.  

Then you could play with low 3.0.0 numbers again :)

Grant.

>It also means something that lets you remember back to what was going on
>for that release better, if you can easily place it within a specific
>time frame, which is important for those of us who work with different
>kernel versions all the time for different projects and backports and
>stable releases.
>
>If the number stays the same, my feeble brain will survive and I'll just
>rely on my huge spreadsheet of when specific kernels were released when
>to get along, and hopefully I will not make any more .26.5 releases when
>I mean .25.5 and such like I have in the past :)
>
>thanks,
>
>greg k-h
-- 
http://bugsplatter.id.au

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16 17:16         ` Adrian Bunk
@ 2008-10-17  4:02           ` Greg KH
  2008-10-17  4:26             ` Grant Coady
                               ` (2 more replies)
  0 siblings, 3 replies; 111+ messages in thread
From: Greg KH @ 2008-10-17  4:02 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Linus Torvalds, linux-kernel

On Thu, Oct 16, 2008 at 08:16:26PM +0300, Adrian Bunk wrote:
> On Thu, Oct 16, 2008 at 08:47:26AM -0700, Greg KH wrote:
> You miss the best alternative:
> 
> Simply keep the status quo.

I'd argue that is is a pain.  Linus has expressed frustration with the
current numbering scheme, and as someone who deals with kernel version
numbers every single day, I too am mildly frustrated.

I think the main reason why is just that small numbers are easier to
keep track of in your mind.  As we are ever increasing the version
number, the release numbers feel like they are getting closer together,
making them less distinguishable.

For example, think of the following:
	2.6.5 vs. 2.6.9
Your mind focuses on the 5 and 9, and in thinking about them, it is much
easier to keep them apart.

Now, try the same with:
	2.6.24 vs. 2.6.27
You are repeating the tens digit, the "two", so it is a bit harder to
distinguish things.  After a few years of this, it gets more difficult

So I proposed an alternative, YEAR.NUMBER.  The year is easy to keep
track of, and the release number is a small one, making it too easier to
track and distinguish from each other:
	2009.1 vs. 2009.5
or
	2010.2 vs. 2011.5
It also means something that lets you remember back to what was going on
for that release better, if you can easily place it within a specific
time frame, which is important for those of us who work with different
kernel versions all the time for different projects and backports and
stable releases.

If the number stays the same, my feeble brain will survive and I'll just
rely on my huge spreadsheet of when specific kernels were released when
to get along, and hopefully I will not make any more .26.5 releases when
I mean .25.5 and such like I have in the past :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16 16:46     ` Adrian Bunk
@ 2008-10-17  3:47       ` Greg KH
  2008-10-17  6:47         ` Adrian Bunk
  0 siblings, 1 reply; 111+ messages in thread
From: Greg KH @ 2008-10-17  3:47 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Linus Torvalds, linux-kernel

On Thu, Oct 16, 2008 at 07:46:02PM +0300, Adrian Bunk wrote:
> On Thu, Oct 16, 2008 at 08:17:48AM -0700, Greg KH wrote:
> > On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
> >...
> > > If a distribution will try to autobuild an urgent OpenSSL security 
> > > update for their stable release in a chroot on a machine running
> > > kernel 2009.2.3 they will surely love you for being responsible
> > > for this...
> > 
> > Distros properly patch things and backport "urgent OpenSSL security
> > updates" to older versions of packages, so they would not run into this
> > problem.
> 
> You didn't get my point.
> 
> Let me make an example:
> 
> The current Debian release will be supported until one year after the
> next release gets released.
> 
> Someone from the Debian security team send a fixed package to the
> buildds.
> 
> The buildds build packages in chroots.
> 
> A buildd may run any Debian release.
> 
> And it's perfectly normal that a buildd runs a more recent release of 
> Debian than the one a package gets built for in a chroot.

So you are saying the Debian build system would build a package for an
older release, on a system that is newer, and that build would be
determining things based on the system it is built on, not what it is
being built for?

If so, then something is very broken already in the Debian build system
and I think you have much bigger problems to worry about right now.

For all other "sane" build systems that I know of, you build against the
libraries/kernel/gcc/glibc/etc that you are wanting to support it for,
not against some random-whatever-happened-to-be-installed-on-the-box.

> No matter what you claim, you suggest to break currently working setups.

No, you have described a broken setup.

Now for new releases, yes, something might have to be changed, but that
is when a sane distro would move to the newly named kernel, not
affecting any old releases at all.

Hope this helps,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16 15:35   ` Theodore Tso
  2008-10-16 18:05     ` John Stoffel
  2008-10-16 19:14     ` Harald Arnesen
@ 2008-10-17  1:53     ` Dave Young
  2008-10-17  9:05       ` Jike Song
  2008-10-20  3:49     ` Daniel Phillips
  3 siblings, 1 reply; 111+ messages in thread
From: Dave Young @ 2008-10-17  1:53 UTC (permalink / raw)
  To: Theodore Tso, linux-kernel

On Thu, Oct 16, 2008 at 11:35 PM, Theodore Tso <tytso@mit.edu> wrote:
> On Thu, Oct 16, 2008 at 04:26:19PM +0200, markus reichelt wrote:
>> Why not just keep it? It has worked so far, and from a strictly
>> end-user point of view I cannot see any advantages at all with a new
>> scheme. The ideas mentioned so far don't cut it either.
>
> I'd cast a vote for keeping it as well.  "2.6" is actually a great
> marker so that people know that it's highly likely the version number
> is for the Linux kernel.  Contrast "I'm running 2.6.27" versus "I'm
> running 27" (huh, what does that mean?) or "I'm running the 27 kernel"
> or "I'm running Linux kernel version 27" or worse yet "I'm running
> 2008-03".  Something like "2.6.27" is just easier to say, and less
> prone to misunderstanding/confusion.
>
> Let's just leave things the way they are.

Agree.

Additionally, we can add some range to x.y.z

such as:

x: 1-9
y: 1-9
z: 1-30

so we can jumo to 2.7.1 after 2.6.30

-- 
Regards
dave

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  0:25 Greg KH
                   ` (6 preceding siblings ...)
  2008-10-16 15:18 ` Geert Uytterhoeven
@ 2008-10-17  1:26 ` Rob Landley
  2008-10-17 12:46 ` Giacomo A. Catenazzi
  8 siblings, 0 replies; 111+ messages in thread
From: Rob Landley @ 2008-10-17  1:26 UTC (permalink / raw)
  To: Greg KH; +Cc: Linus Torvalds, linux-kernel

On Wednesday 15 October 2008 19:25:09 Greg KH wrote:
> Hi,
>
> You brought this topic up a few months ago, and passed it off as
> something we would discuss at the kernel summit.  But that never
> happened, so I figured I'd bring it up again here.
>
> So, as someone who constantly is dealing with kernel version numbers all
> the time with the -stable trees, our current numbering scheme is a pain
> a times.  How about this proposal instead?

I don't understand, what exactly is a pain about it?  (I can't tell why a new 
one is better if you don't say what you're objecting to about the old one...)

> Benefits of this is it more accuratly represents to people just how old
> the kernel they are currently running is (2.6.9 would be have been
> 2004.9.0 on this naming scheme.)

Benefits is plural, but I seem to have missed the other ones.  Or is that the 
only issue, wanting to put a more prominent "best if used by" date in the 
name ala Windows 95?

Rob

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16 15:35   ` Theodore Tso
  2008-10-16 18:05     ` John Stoffel
@ 2008-10-16 19:14     ` Harald Arnesen
  2008-10-17  1:53     ` Dave Young
  2008-10-20  3:49     ` Daniel Phillips
  3 siblings, 0 replies; 111+ messages in thread
From: Harald Arnesen @ 2008-10-16 19:14 UTC (permalink / raw)
  To: Theodore Tso; +Cc: linux-kernel

Theodore Tso <tytso@mit.edu> writes:

> On Thu, Oct 16, 2008 at 04:26:19PM +0200, markus reichelt wrote:
>> Why not just keep it? It has worked so far, and from a strictly
>> end-user point of view I cannot see any advantages at all with a new
>> scheme. The ideas mentioned so far don't cut it either.
>
> I'd cast a vote for keeping it as well.  "2.6" is actually a great
> marker so that people know that it's highly likely the version number
> is for the Linux kernel.  Contrast "I'm running 2.6.27" versus "I'm
> running 27" (huh, what does that mean?) or "I'm running the 27 kernel"
> or "I'm running Linux kernel version 27" or worse yet "I'm running
> 2008-03".  Something like "2.6.27" is just easier to say, and less
> prone to misunderstanding/confusion.
>
> Let's just leave things the way they are.

My suggestion: When 2.6.28 is released, rename it to 2.8 (or 2.8.0).
The next one will be 2.9, then 2.10 and so on. Today's 2.6.x.y will be
2.8.y.

It should minimise breakage of userspace programs.

Or wait til 2.6.30, and rename that to 3.0.
-- 
Hilsen Harald.

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16 15:35   ` Theodore Tso
@ 2008-10-16 18:05     ` John Stoffel
  2008-10-16 19:14     ` Harald Arnesen
                       ` (2 subsequent siblings)
  3 siblings, 0 replies; 111+ messages in thread
From: John Stoffel @ 2008-10-16 18:05 UTC (permalink / raw)
  To: Theodore Tso; +Cc: linux-kernel

>>>>> "Theodore" == Theodore Tso <tytso@mit.edu> writes:

Theodore> On Thu, Oct 16, 2008 at 04:26:19PM +0200, markus reichelt wrote:
>> Why not just keep it? It has worked so far, and from a strictly
>> end-user point of view I cannot see any advantages at all with a new
>> scheme. The ideas mentioned so far don't cut it either.

Theodore> I'd cast a vote for keeping it as well.  "2.6" is actually a
Theodore> great marker so that people know that it's highly likely the
Theodore> version number is for the Linux kernel.  Contrast "I'm
Theodore> running 2.6.27" versus "I'm running 27" (huh, what does that
Theodore> mean?) or "I'm running the 27 kernel" or "I'm running Linux
Theodore> kernel version 27" or worse yet "I'm running 2008-03".
Theodore> Something like "2.6.27" is just easier to say, and less
Theodore> prone to misunderstanding/confusion.

I dunno... I like the *idea* of a date string, but maybe it needs to
be in parallel and not replace the 2.6.x we have currently?  God knows
a bunch of stuff is going to break when we get to 2.6.100 or 2.>6 or
3.x or whatever.  

But, having something which encodes the release date into the version
string would be useful as well.  On my home debian box I get:

> uname -a
Linux jfsnew 2.6.26 #17 SMP Mon Jul 21 18:58:42 EDT 2008 i686 GNU/Linux

So having "2.6.16 (2008/MM/DD) #17 ..." would be great with me.  But
people would need to think it through more carefully...

John


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  9:33     ` el es
  2008-10-16 10:05       ` el es
@ 2008-10-16 17:30       ` david
  1 sibling, 0 replies; 111+ messages in thread
From: david @ 2008-10-16 17:30 UTC (permalink / raw)
  To: el es; +Cc: linux-kernel

On Thu, 16 Oct 2008, el es wrote:

> H. Peter Anvin <hpa <at> zytor.com> writes:
>> el es wrote:
> [snip]
>>> - informative : the ww and tt numbers are the week numbers of when the actual
>>>
>>> release HAPPENED, not when it is predicted.
>>>
>>
>> Which really sucks for dealing with future releases.
>>
>
> Why ?
> What do you mean by 'future releases' ?
> Can you predict exactly when the next release will happen ? The current practice
> of -rcX shows clearly you cannot.

that's the point

> Moreover, with my idea you could easily say, which stable release is still
> supported (and how old its mainline really was) up to the week, which IMHO is
> granular enough.

huh?? kernels are not supported for X amount of time, so this isn't 
relevant information for support. kernels are 'supported' until some time 
after the next kernel is released.

> Also you could for sure say, that e.g. a device/software that hit market in say
> December this year, will be compatible with e.g. 2.09.XX+ - look at users POV.

no you can't, the fact that a kernel was released in December and the 
product was released in November tells you nothing about the probability 
that that hardware is supported by that kernel.

you can't even say that a kernel released in 2009 supports hardware 
released in 2007.

David Lang

> Current scheme is great, established and understandable, but sucks at this
> point : for any product, be it hardware or software, you need to print both its
> date of creation AND the minimum kernel that supports it. With my idea, it is
> only the date you need.
>
>> 	-hpa
>>
>
> Lukasz
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16 15:47       ` Greg KH
@ 2008-10-16 17:16         ` Adrian Bunk
  2008-10-17  4:02           ` Greg KH
  0 siblings, 1 reply; 111+ messages in thread
From: Adrian Bunk @ 2008-10-16 17:16 UTC (permalink / raw)
  To: Greg KH; +Cc: Linus Torvalds, linux-kernel

On Thu, Oct 16, 2008 at 08:47:26AM -0700, Greg KH wrote:
> On Thu, Oct 16, 2008 at 11:30:53AM -0400, Bill Nottingham wrote:
> > Greg KH (greg@kroah.com) said: 
> > > Distros properly patch things and backport "urgent OpenSSL security
> > > updates" to older versions of packages, so they would not run into this
> > > problem.
> > > 
> > > Newer releases would run into this problem, but as almost all distros
> > > have huge, easy to run, build systems, a change like this would show up
> > > immediately and be fixed in a matter of hours, with the needed fixes
> > > being pushed upstream to the various packages as needed.
> > > 
> > > So I really don't think this is much of a problem.
> > > 
> > > It's interesting that openssl doesn't just check for Linux 1.x and
> > > assumes that Linux 9.23.12 will work just fine with what they are doing :)
> > 
> > Is it really worth the effort of having any such upstream have to
> > quickly patch and release, when the only benefit listed (earlier in
> > this thread) was to inform people how old their kernel is?
> 
> If we switch to a consecutive numbering scheme, which doesn't show the
> "age" of the kernel, we would still have to patch such packages, so I
> don't see the big difference.

You miss the best alternative:

Simply keep the status quo.

> thanks,
> 
> greg k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16 15:17   ` Greg KH
  2008-10-16 15:30     ` Bill Nottingham
@ 2008-10-16 16:46     ` Adrian Bunk
  2008-10-17  3:47       ` Greg KH
  1 sibling, 1 reply; 111+ messages in thread
From: Adrian Bunk @ 2008-10-16 16:46 UTC (permalink / raw)
  To: Greg KH; +Cc: Linus Torvalds, linux-kernel

On Thu, Oct 16, 2008 at 08:17:48AM -0700, Greg KH wrote:
> On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
>...
> > If a distribution will try to autobuild an urgent OpenSSL security 
> > update for their stable release in a chroot on a machine running
> > kernel 2009.2.3 they will surely love you for being responsible
> > for this...
> 
> Distros properly patch things and backport "urgent OpenSSL security
> updates" to older versions of packages, so they would not run into this
> problem.

You didn't get my point.

Let me make an example:

The current Debian release will be supported until one year after the
next release gets released.

Someone from the Debian security team send a fixed package to the
buildds.

The buildds build packages in chroots.

A buildd may run any Debian release.

And it's perfectly normal that a buildd runs a more recent release of 
Debian than the one a package gets built for in a chroot.

No matter what you claim, you suggest to break currently working setups.

> Newer releases would run into this problem, but as almost all distros
> have huge, easy to run, build systems, a change like this would show up
> immediately and be fixed in a matter of hours, with the needed fixes
> being pushed upstream to the various packages as needed.
> 
> So I really don't think this is much of a problem.
>...

Using the same logic we could drop all legacy userspace ABIs
immediately - after all, it should only be a matter of hours
for a distribution to e.g. upgrade their glibc to 2.8 ...

You cannot suggest to change something that is some kind of informal 
userspace ABI and the claim it was not much of a problem.

I don't know what exactly would break, but various places in userspace 
would break in perhaps unexpected and strange ways, and this would cause 
many people quite a bit of headaches and work.

And I don't see any *really* good reason that would justify such
a change in the versioning.

> thanks,
> 
> greg k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16 15:30     ` Bill Nottingham
@ 2008-10-16 15:47       ` Greg KH
  2008-10-16 17:16         ` Adrian Bunk
  0 siblings, 1 reply; 111+ messages in thread
From: Greg KH @ 2008-10-16 15:47 UTC (permalink / raw)
  To: Adrian Bunk, Linus Torvalds, linux-kernel

On Thu, Oct 16, 2008 at 11:30:53AM -0400, Bill Nottingham wrote:
> Greg KH (greg@kroah.com) said: 
> > Distros properly patch things and backport "urgent OpenSSL security
> > updates" to older versions of packages, so they would not run into this
> > problem.
> > 
> > Newer releases would run into this problem, but as almost all distros
> > have huge, easy to run, build systems, a change like this would show up
> > immediately and be fixed in a matter of hours, with the needed fixes
> > being pushed upstream to the various packages as needed.
> > 
> > So I really don't think this is much of a problem.
> > 
> > It's interesting that openssl doesn't just check for Linux 1.x and
> > assumes that Linux 9.23.12 will work just fine with what they are doing :)
> 
> Is it really worth the effort of having any such upstream have to
> quickly patch and release, when the only benefit listed (earlier in
> this thread) was to inform people how old their kernel is?

If we switch to a consecutive numbering scheme, which doesn't show the
"age" of the kernel, we would still have to patch such packages, so I
don't see the big difference.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16 14:26 ` markus reichelt
@ 2008-10-16 15:35   ` Theodore Tso
  2008-10-16 18:05     ` John Stoffel
                       ` (3 more replies)
  0 siblings, 4 replies; 111+ messages in thread
From: Theodore Tso @ 2008-10-16 15:35 UTC (permalink / raw)
  To: linux-kernel

On Thu, Oct 16, 2008 at 04:26:19PM +0200, markus reichelt wrote:
> Why not just keep it? It has worked so far, and from a strictly
> end-user point of view I cannot see any advantages at all with a new
> scheme. The ideas mentioned so far don't cut it either.

I'd cast a vote for keeping it as well.  "2.6" is actually a great
marker so that people know that it's highly likely the version number
is for the Linux kernel.  Contrast "I'm running 2.6.27" versus "I'm
running 27" (huh, what does that mean?) or "I'm running the 27 kernel"
or "I'm running Linux kernel version 27" or worse yet "I'm running
2008-03".  Something like "2.6.27" is just easier to say, and less
prone to misunderstanding/confusion.

Let's just leave things the way they are.

					- Ted

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16 15:17   ` Greg KH
@ 2008-10-16 15:30     ` Bill Nottingham
  2008-10-16 15:47       ` Greg KH
  2008-10-16 16:46     ` Adrian Bunk
  1 sibling, 1 reply; 111+ messages in thread
From: Bill Nottingham @ 2008-10-16 15:30 UTC (permalink / raw)
  To: Greg KH; +Cc: Adrian Bunk, Linus Torvalds, linux-kernel

Greg KH (greg@kroah.com) said: 
> Distros properly patch things and backport "urgent OpenSSL security
> updates" to older versions of packages, so they would not run into this
> problem.
> 
> Newer releases would run into this problem, but as almost all distros
> have huge, easy to run, build systems, a change like this would show up
> immediately and be fixed in a matter of hours, with the needed fixes
> being pushed upstream to the various packages as needed.
> 
> So I really don't think this is much of a problem.
> 
> It's interesting that openssl doesn't just check for Linux 1.x and
> assumes that Linux 9.23.12 will work just fine with what they are doing :)

Is it really worth the effort of having any such upstream have to
quickly patch and release, when the only benefit listed (earlier in
this thread) was to inform people how old their kernel is?

Bill

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  9:15 ` Hans J. Koch
@ 2008-10-16 15:21   ` Geert Uytterhoeven
  2008-10-18 21:56   ` Jan Engelhardt
  1 sibling, 0 replies; 111+ messages in thread
From: Geert Uytterhoeven @ 2008-10-16 15:21 UTC (permalink / raw)
  To: Hans J. Koch; +Cc: Greg KH, Linus Torvalds, linux-kernel

On Thu, 16 Oct 2008, Hans J. Koch wrote:
> On Wed, Oct 15, 2008 at 05:25:09PM -0700, Greg KH wrote:
> > Benefits of this is it more accuratly represents to people just how old
> > the kernel they are currently running is (2.6.9 would be have been
> > 2004.9.0 on this naming scheme.)
> 
> That would be a nice advantage, especially in embedded land where
> industry people frequently use ancient kernels. OTOH, those people also
> still use Windows 2000 without realizing what the "2000" implies.

If you want to leapfrog Microsoft (and perhaps want to bring a tribute
to UNIX at the same time?), just call the next version Linux 7.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  0:25 Greg KH
                   ` (5 preceding siblings ...)
  2008-10-16 14:26 ` markus reichelt
@ 2008-10-16 15:18 ` Geert Uytterhoeven
  2008-10-17  1:26 ` Rob Landley
  2008-10-17 12:46 ` Giacomo A. Catenazzi
  8 siblings, 0 replies; 111+ messages in thread
From: Geert Uytterhoeven @ 2008-10-16 15:18 UTC (permalink / raw)
  To: Greg KH; +Cc: Linus Torvalds, linux-kernel

On Wed, 15 Oct 2008, Greg KH wrote:
> You brought this topic up a few months ago, and passed it off as
> something we would discuss at the kernel summit.  But that never
> happened, so I figured I'd bring it up again here.
> 
> So, as someone who constantly is dealing with kernel version numbers all
> the time with the -stable trees, our current numbering scheme is a pain
> a times.  How about this proposal instead?

> Any thoughts?
> 
> Let the bike-shedding begin!

What about just using the git SHA1?

Advantages:
  - We're all getting older. Training our memory to remember SHA1 IDs is
    actually good for us!
  - Perhaps Google will finally start tracking git commits, so I can
    feed them a git commit ID mentioned in a random email and find the
    actual commit, without having to know to which repository it
    belongs?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16 12:49 ` Adrian Bunk
@ 2008-10-16 15:17   ` Greg KH
  2008-10-16 15:30     ` Bill Nottingham
  2008-10-16 16:46     ` Adrian Bunk
  0 siblings, 2 replies; 111+ messages in thread
From: Greg KH @ 2008-10-16 15:17 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Linus Torvalds, linux-kernel

On Thu, Oct 16, 2008 at 03:49:43PM +0300, Adrian Bunk wrote:
> On Wed, Oct 15, 2008 at 05:25:09PM -0700, Greg KH wrote:
> > Hi,
> 
> Hi Greg,
> 
> >...
> > Yes, we can handle the major/minor macros in the kernel to provide a
> > compatible number so that automated scripts will not break, that's not a
> > big deal.
> > 
> > Any thoughts?
> >...
> 
> how much of userspace breaks when we suddenly "just for fun" change the 
> version numbering scheme in a very radical way?
> 
> I'm not thinking of scripts for building the kernel.
> 
> I'm thinking of the fact that starting with glibc different pieces of 
> userspace software interpret the kernel version number they get from 
> various sources like e.g. <linux/version.h>, "uname -r" or an ioctl.
> 
> As a random example, the "config" script of OpenSSL 0.9.8g contains the 
> following:
> 
> <--  snip  -->
> 
> ...
> RELEASE=`(uname -r) 2>/dev/null` || RELEASE="unknown"
> ...
> case "${SYSTEM}:${RELEASE}:${VERSION}:${MACHINE}" in
> ...
>     Linux:[2-9].*)
>         echo "${MACHINE}-whatever-linux2"; exit 0
>         ;;
> 
>     Linux:1.*)
>         echo "${MACHINE}-whatever-linux1"; exit 0
>         ;;
> ...
> 
> <--  snip  -->
> 
> 
> Change the version number of the kernel in the way you suggest, and 
> trying to build it will fail with:
> 
> <--  snip  -->
> 
> $ ./config
> Operating system: x86_64-whatever-Linux
> This system (Linux) is not supported. See file INSTALL for details.
> $ 
> 
> <--  snip  -->
> 
> 
> If a distribution will try to autobuild an urgent OpenSSL security 
> update for their stable release in a chroot on a machine running
> kernel 2009.2.3 they will surely love you for being responsible
> for this...

Distros properly patch things and backport "urgent OpenSSL security
updates" to older versions of packages, so they would not run into this
problem.

Newer releases would run into this problem, but as almost all distros
have huge, easy to run, build systems, a change like this would show up
immediately and be fixed in a matter of hours, with the needed fixes
being pushed upstream to the various packages as needed.

So I really don't think this is much of a problem.

It's interesting that openssl doesn't just check for Linux 1.x and
assumes that Linux 9.23.12 will work just fine with what they are doing :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  0:25 Greg KH
                   ` (4 preceding siblings ...)
  2008-10-16 12:49 ` Adrian Bunk
@ 2008-10-16 14:26 ` markus reichelt
  2008-10-16 15:35   ` Theodore Tso
  2008-10-16 15:18 ` Geert Uytterhoeven
                   ` (2 subsequent siblings)
  8 siblings, 1 reply; 111+ messages in thread
From: markus reichelt @ 2008-10-16 14:26 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

* Greg KH <greg@kroah.com> wrote:

> So, as someone who constantly is dealing with kernel version
> numbers all the time with the -stable trees, our current numbering
> scheme is a pain a times.  How about this proposal instead?

Why not just keep it? It has worked so far, and from a strictly
end-user point of view I cannot see any advantages at all with a new
scheme. The ideas mentioned so far don't cut it either.

Just my heretic 2 cents,
S.

PS: Nice timing, thunderstorm approaching.

-- 
In Russia, President kills Financial Crisis

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  0:25 Greg KH
                   ` (3 preceding siblings ...)
  2008-10-16  9:15 ` Hans J. Koch
@ 2008-10-16 12:49 ` Adrian Bunk
  2008-10-16 15:17   ` Greg KH
  2008-10-16 14:26 ` markus reichelt
                   ` (3 subsequent siblings)
  8 siblings, 1 reply; 111+ messages in thread
From: Adrian Bunk @ 2008-10-16 12:49 UTC (permalink / raw)
  To: Greg KH; +Cc: Linus Torvalds, linux-kernel

On Wed, Oct 15, 2008 at 05:25:09PM -0700, Greg KH wrote:
> Hi,

Hi Greg,

>...
> Yes, we can handle the major/minor macros in the kernel to provide a
> compatible number so that automated scripts will not break, that's not a
> big deal.
> 
> Any thoughts?
>...

how much of userspace breaks when we suddenly "just for fun" change the 
version numbering scheme in a very radical way?

I'm not thinking of scripts for building the kernel.

I'm thinking of the fact that starting with glibc different pieces of 
userspace software interpret the kernel version number they get from 
various sources like e.g. <linux/version.h>, "uname -r" or an ioctl.

As a random example, the "config" script of OpenSSL 0.9.8g contains the 
following:

<--  snip  -->

...
RELEASE=`(uname -r) 2>/dev/null` || RELEASE="unknown"
...
case "${SYSTEM}:${RELEASE}:${VERSION}:${MACHINE}" in
...
    Linux:[2-9].*)
        echo "${MACHINE}-whatever-linux2"; exit 0
        ;;

    Linux:1.*)
        echo "${MACHINE}-whatever-linux1"; exit 0
        ;;
...

<--  snip  -->


Change the version number of the kernel in the way you suggest, and 
trying to build it will fail with:

<--  snip  -->

$ ./config
Operating system: x86_64-whatever-Linux
This system (Linux) is not supported. See file INSTALL for details.
$ 

<--  snip  -->


If a distribution will try to autobuild an urgent OpenSSL security 
update for their stable release in a chroot on a machine running
kernel 2009.2.3 they will surely love you for being responsible
for this...


> thanks,
> 
> greg k-h

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16 10:05       ` el es
@ 2008-10-16 10:14         ` Kristoffer Ericson
  0 siblings, 0 replies; 111+ messages in thread
From: Kristoffer Ericson @ 2008-10-16 10:14 UTC (permalink / raw)
  To: el es; +Cc: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

Please don't use time indications inside kernel versions, it just gets confusing
(even more so if you use yy mm dd).


On Thu, 16 Oct 2008 10:05:32 +0000 (UTC)
el es <el_es_cr@yahoo.co.uk> wrote:

> el es <el_es_cr <at> yahoo.co.uk> writes:
> 
> > 
> > H. Peter Anvin <hpa <at> zytor.com> writes:
> > 
> > > 
> > > el es wrote:
> > [snip]
> > > > - informative : the ww and tt numbers are the week numbers of when the 
> > > > actual release HAPPENED, not when it is predicted.
> 
> > > Which really sucks for dealing with future releases.
> > > 
> > 
> > Why ? 
> > What do you mean by 'future releases' ? 
> 
> Oh, I just read your suggestion to move on with 3, 4 and so on. To keep it 
> simple.
> 
> How about adopting your scheme (simple counter) with mine (yy.ww.tt) ?
> 
> Speaking on my own, I think that some indication of WHEN the release actually
> happened, encoded in the version number, IS desirable. I'm not a developer (my
> field is far, far away) but personally I find the suggestions to put full year
> figure in front, grossly disturbing everything we accustomed to ;)
> 
> OR.
> If in my idea, we drop the .tt bit, hence, we declare, that the stable team just
> continues the work on the released version, like
> 
> - 2.08.41 is the currently released 2.6.27,
> - developers continue on 2.08.41-rcX, which gets promoted to 3.yy.ww when 
> released and so on,
> - meanwhile the stable team releases 2.08.[42..52], 2.09.[01..52] and so on. 
> 
> Being an indication of continuity.
> As well as a revolution too ;)
> > > 
> > 
> > Lukasz
> > 
> > 
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


-- 
Kristoffer Ericson <kristoffer.ericson@gmail.com>

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  9:33     ` el es
@ 2008-10-16 10:05       ` el es
  2008-10-16 10:14         ` Kristoffer Ericson
  2008-10-16 17:30       ` david
  1 sibling, 1 reply; 111+ messages in thread
From: el es @ 2008-10-16 10:05 UTC (permalink / raw)
  To: linux-kernel

el es <el_es_cr <at> yahoo.co.uk> writes:

> 
> H. Peter Anvin <hpa <at> zytor.com> writes:
> 
> > 
> > el es wrote:
> [snip]
> > > - informative : the ww and tt numbers are the week numbers of when the 
> > > actual release HAPPENED, not when it is predicted.

> > Which really sucks for dealing with future releases.
> > 
> 
> Why ? 
> What do you mean by 'future releases' ? 

Oh, I just read your suggestion to move on with 3, 4 and so on. To keep it 
simple.

How about adopting your scheme (simple counter) with mine (yy.ww.tt) ?

Speaking on my own, I think that some indication of WHEN the release actually
happened, encoded in the version number, IS desirable. I'm not a developer (my
field is far, far away) but personally I find the suggestions to put full year
figure in front, grossly disturbing everything we accustomed to ;)

OR.
If in my idea, we drop the .tt bit, hence, we declare, that the stable team just
continues the work on the released version, like

- 2.08.41 is the currently released 2.6.27,
- developers continue on 2.08.41-rcX, which gets promoted to 3.yy.ww when 
released and so on,
- meanwhile the stable team releases 2.08.[42..52], 2.09.[01..52] and so on. 

Being an indication of continuity.
As well as a revolution too ;)
> > 
> 
> Lukasz
> 
> 





^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  9:09   ` H. Peter Anvin
@ 2008-10-16  9:33     ` el es
  2008-10-16 10:05       ` el es
  2008-10-16 17:30       ` david
  0 siblings, 2 replies; 111+ messages in thread
From: el es @ 2008-10-16  9:33 UTC (permalink / raw)
  To: linux-kernel

H. Peter Anvin <hpa <at> zytor.com> writes:

> 
> el es wrote:
[snip]
> > - informative : the ww and tt numbers are the week numbers of when the actual
> > 
> > release HAPPENED, not when it is predicted.
> > 
> 
> Which really sucks for dealing with future releases.
> 

Why ? 
What do you mean by 'future releases' ? 
Can you predict exactly when the next release will happen ? The current practice 
of -rcX shows clearly you cannot. 

Moreover, with my idea you could easily say, which stable release is still
supported (and how old its mainline really was) up to the week, which IMHO is
granular enough.
Also you could for sure say, that e.g. a device/software that hit market in say 
December this year, will be compatible with e.g. 2.09.XX+ - look at users POV. 

Current scheme is great, established and understandable, but sucks at this 
point : for any product, be it hardware or software, you need to print both its 
date of creation AND the minimum kernel that supports it. With my idea, it is 
only the date you need. 

> 	-hpa
> 

Lukasz



^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  0:25 Greg KH
                   ` (2 preceding siblings ...)
  2008-10-16  8:21 ` el es
@ 2008-10-16  9:15 ` Hans J. Koch
  2008-10-16 15:21   ` Geert Uytterhoeven
  2008-10-18 21:56   ` Jan Engelhardt
  2008-10-16 12:49 ` Adrian Bunk
                   ` (4 subsequent siblings)
  8 siblings, 2 replies; 111+ messages in thread
From: Hans J. Koch @ 2008-10-16  9:15 UTC (permalink / raw)
  To: Greg KH; +Cc: Linus Torvalds, linux-kernel

On Wed, Oct 15, 2008 at 05:25:09PM -0700, Greg KH wrote:
> 
> Benefits of this is it more accuratly represents to people just how old
> the kernel they are currently running is (2.6.9 would be have been
> 2004.9.0 on this naming scheme.)

That would be a nice advantage, especially in embedded land where
industry people frequently use ancient kernels. OTOH, those people also
still use Windows 2000 without realizing what the "2000" implies.

Hans


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  8:21 ` el es
@ 2008-10-16  9:09   ` H. Peter Anvin
  2008-10-16  9:33     ` el es
  0 siblings, 1 reply; 111+ messages in thread
From: H. Peter Anvin @ 2008-10-16  9:09 UTC (permalink / raw)
  To: el es; +Cc: linux-kernel

el es wrote:
> 
> the scheme to be s.yy.ww.tt, that is :
> 
> s - series, as it is now (freedom to Linus to declare a whole 'new generation'
> 
> ;) if he wanted  )
> 
> yy - two (in a hundred years, three) digits of the year
> 
> Now the interesting part begins which is
> 
> ww - the number of the week of the release. This will be between 1 and 52 (53)
> 
> tt - the number of the week of stable release. As above.
> 
> It is:
> - most similar to the scheme used so far,
> - informative : the ww and tt numbers are the week numbers of when the actual
> 
> release HAPPENED, not when it is predicted.
> 

Which really sucks for dealing with future releases.

	-hpa

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  0:25 Greg KH
  2008-10-16  1:03 ` H. Peter Anvin
  2008-10-16  7:02 ` Thorsten Leemhuis
@ 2008-10-16  8:21 ` el es
  2008-10-16  9:09   ` H. Peter Anvin
  2008-10-16  9:15 ` Hans J. Koch
                   ` (5 subsequent siblings)
  8 siblings, 1 reply; 111+ messages in thread
From: el es @ 2008-10-16  8:21 UTC (permalink / raw)
  To: linux-kernel

Greg KH <greg <at> kroah.com> writes:

> 
> Hi,
> 
> You brought this topic up a few months ago, and passed it off as
> something we would discuss at the kernel summit.  But that never
> happened, so I figured I'd bring it up again here.
> 
> So, as someone who constantly is dealing with kernel version numbers all
> the time with the -stable trees, our current numbering scheme is a pain
> a times.  How about this proposal instead?
> 
> We number the kernel based on the year, and the numbers of releases we
> have done this year:
> 	YEAR.NUMBER.MINOR_RELEASE
> 

I strongly disagree about the full year indication in front ;) 

and bring up my older idea of

the scheme to be s.yy.ww.tt, that is :

s - series, as it is now (freedom to Linus to declare a whole 'new generation'

;) if he wanted  )

yy - two (in a hundred years, three) digits of the year

Now the interesting part begins which is

ww - the number of the week of the release. This will be between 1 and 52 (53)

tt - the number of the week of stable release. As above.

It is:
- most similar to the scheme used so far,
- informative : the ww and tt numbers are the week numbers of when the actual

release HAPPENED, not when it is predicted.

- easy to put some automation into it (git release HEAD now ) could branch the

current and rename it accordingly (not that I know how to do it, just

imagination)

- (mod) in case there are more than one release in a week, letters could be 

used (e.g. 2.08.44[a..z]) in as many count as needed (2.08.45deadbeef.50sodead 
)(or put the git commit indication there ?)

- in case the stable releases go forth into next year or over, the stable team

puts additional .yy.ww instead of their own .tt (like 2.08.45.09.05) (yes I know

it is long)

- the -rc releases go as usual beginning with latest mainline release

(2.08.45-rcX, X being a number as it is now)

- dubbing behavior of silicon manufacturers who print the actual week number of

production onto their chips - imagine looking at a chip and quick glancing at

the kernel version number and _knowing_ it should be OK ;)


My £0.02 ;)
> 
> Any thoughts?
> 
> Let the bike-shedding begin!
> 
> thanks,
> 
> greg k-h
> 

Lukasz



^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  7:02 ` Thorsten Leemhuis
@ 2008-10-16  7:34   ` david
  2008-10-18 21:44     ` Jan Engelhardt
  0 siblings, 1 reply; 111+ messages in thread
From: david @ 2008-10-16  7:34 UTC (permalink / raw)
  To: Thorsten Leemhuis; +Cc: Greg KH, Linus Torvalds, linux-kernel

On Thu, 16 Oct 2008, Thorsten Leemhuis wrote:

> On 16.10.2008 02:25, Greg KH wrote:
>> You brought this topic up a few months ago, and passed it off as
>> something we would discuss at the kernel summit.  But that never
>> happened, so I figured I'd bring it up again here.
>> 
>> So, as someone who constantly is dealing with kernel version numbers all
>> the time with the -stable trees, our current numbering scheme is a pain
>> a times.  How about this proposal instead?
>> 
>> We number the kernel based on the year, and the numbers of releases we
>> have done this year:
>> 	YEAR.NUMBER.MINOR_RELEASE
>> 
>> For example, the first release in 2009 would be called:
>> 	2009.0.0
>> The second:
>> 	2009.1.0
>> [...]
>
> That afaics has one minor downside: You don't know in advance how the next 
> kernel is going to be called. Example: the kernel that is currently developed 
> could become 2008.4 (the fifth kernel in 2008) if this development cycle in 
> the end is one of the quicker ones and gets finished this year. But if 
> everything is a bit slower then it might become 2009.0 (the first one in 
> 2009).
>
> Hence people that write a lot of articles about things that happen in linux 
> land (like LWN.net or I do) would be forced to write sentences like "[...]the 
> kernel that will become 2008.3 or 2009.0 will have feature foo that works 
> like this[...]". That will get really confusing if you read those articles 
> half a year later -- especially if that kernel became 2008.3 in the end, 
> because foo in 2009.0 might already look quite different again...

pick a name when the merge window opens

either based on when the merge window opens, or when it's expected to be 
released (and accept that you may have a 2008.3 released in early 2009, or 
a 2009.1 released in december 2008)

David Lang

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  0:25 Greg KH
  2008-10-16  1:03 ` H. Peter Anvin
@ 2008-10-16  7:02 ` Thorsten Leemhuis
  2008-10-16  7:34   ` david
  2008-10-16  8:21 ` el es
                   ` (6 subsequent siblings)
  8 siblings, 1 reply; 111+ messages in thread
From: Thorsten Leemhuis @ 2008-10-16  7:02 UTC (permalink / raw)
  To: Greg KH; +Cc: Linus Torvalds, linux-kernel

On 16.10.2008 02:25, Greg KH wrote:
> You brought this topic up a few months ago, and passed it off as
> something we would discuss at the kernel summit.  But that never
> happened, so I figured I'd bring it up again here.
> 
> So, as someone who constantly is dealing with kernel version numbers all
> the time with the -stable trees, our current numbering scheme is a pain
> a times.  How about this proposal instead?
> 
> We number the kernel based on the year, and the numbers of releases we
> have done this year:
> 	YEAR.NUMBER.MINOR_RELEASE
> 
> For example, the first release in 2009 would be called:
> 	2009.0.0
> The second:
> 	2009.1.0
> [...]

That afaics has one minor downside: You don't know in advance how the 
next kernel is going to be called. Example: the kernel that is currently 
developed could become 2008.4 (the fifth kernel in 2008) if this 
development cycle in the end is one of the quicker ones and gets 
finished this year. But if everything is a bit slower then it might 
become 2009.0 (the first one in 2009).

Hence people that write a lot of articles about things that happen in 
linux land (like LWN.net or I do) would be forced to write sentences 
like "[...]the kernel that will become 2008.3 or 2009.0 will have 
feature foo that works like this[...]". That will get really confusing 
if you read those articles half a year later -- especially if that 
kernel became 2008.3 in the end, because foo in 2009.0 might already 
look quite different again...

> [...] Let the bike-shedding begin!

Please paint a tux on top of the roof.

CU
thl
-- 
Thorsten Leemhuis
  c't- Magazin für Computertechnik       web    http://www.heise.de/ct/
  Heise Zeitschriften Verlag GmbH&Co.KG  phone  +49 (0)511 5352 300
  Helstorfer Str. 7                      icq    140593172
  D-30625 Hannover, Germany              jabber thl_at_work@jabber.ccc.de

/* Heise Zeitschriften Verlag GmbH & Co. KG, Registergericht:
    Amtsgericht Hannover HRA 26709; Persönlich haftende Gesellschafterin:
    Heise Zeitschriften Verlag Geschäftsführung GmbH, Registergericht:
    Amtsgericht Hannover, HRB 60405 Geschäftsführer: Ansgar Heise,
    Steven P. Steinkraus, Dr. Alfons Schräder                          */

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  1:03 ` H. Peter Anvin
  2008-10-16  1:51   ` David Sanders
@ 2008-10-16  2:18   ` Greg KH
  1 sibling, 0 replies; 111+ messages in thread
From: Greg KH @ 2008-10-16  2:18 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Linus Torvalds, linux-kernel

On Wed, Oct 15, 2008 at 06:03:37PM -0700, H. Peter Anvin wrote:
> Greg KH wrote:
>> Yes, we can handle the major/minor macros in the kernel to provide a
>> compatible number so that automated scripts will not break, that's not a
>> big deal.
>> Any thoughts?
>> Let the bike-shedding begin!
>
> Personally I find that having a simple counter is kind of nice, simply 
> because one can talk about 27, 28, 29, ... and actually be able to rely on 
> it being stable.

I would love to do that, start with 28.0 and go from there.

It's just a number, might as well just treat it as such :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

* RE: [RFC] Kernel version numbering scheme change
@ 2008-10-16  2:10 H. Peter Anvin
  0 siblings, 0 replies; 111+ messages in thread
From: H. Peter Anvin @ 2008-10-16  2:10 UTC (permalink / raw)
  To: David Sanders; +Cc: Greg KH, Linus Torvalds, linux-kernel

That would seem to combine the worst of both...

-- 
Sent from my mobile phone (pardon any lack of formatting)


-----Original Message-----
From: David Sanders <linux@sandersweb.net>
Sent: Wednesday, October 15, 2008 18:51
To: H. Peter Anvin <hpa@zytor.com>
Cc: Greg KH <greg@kroah.com>; Linus Torvalds <torvalds@linux-foundation.org>; linux-kernel@vger.kernel.org
Subject: Re: [RFC] Kernel version numbering scheme change

On Wednesday 15 October 2008 09:03:37 pm H. Peter Anvin wrote:
> Greg KH wrote:
> > Yes, we can handle the major/minor macros in the kernel to provide a
> > compatible number so that automated scripts will not break, that's not a
> > big deal.
> >
> Personally I find that having a simple counter is kind of nice, simply
> because one can talk about 27, 28, 29, ... and actually be able to rely
> on it being stable.

How  about 2008.27.0, 2008.27.1, 2008.28.0, ...
David


^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  1:03 ` H. Peter Anvin
@ 2008-10-16  1:51   ` David Sanders
  2008-10-16  2:18   ` Greg KH
  1 sibling, 0 replies; 111+ messages in thread
From: David Sanders @ 2008-10-16  1:51 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Greg KH, Linus Torvalds, linux-kernel

On Wednesday 15 October 2008 09:03:37 pm H. Peter Anvin wrote:
> Greg KH wrote:
> > Yes, we can handle the major/minor macros in the kernel to provide a
> > compatible number so that automated scripts will not break, that's not a
> > big deal.
> >
> Personally I find that having a simple counter is kind of nice, simply
> because one can talk about 27, 28, 29, ... and actually be able to rely
> on it being stable.

How  about 2008.27.0, 2008.27.1, 2008.28.0, ...
David

^ permalink raw reply	[flat|nested] 111+ messages in thread

* Re: [RFC] Kernel version numbering scheme change
  2008-10-16  0:25 Greg KH
@ 2008-10-16  1:03 ` H. Peter Anvin
  2008-10-16  1:51   ` David Sanders
  2008-10-16  2:18   ` Greg KH
  2008-10-16  7:02 ` Thorsten Leemhuis
                   ` (7 subsequent siblings)
  8 siblings, 2 replies; 111+ messages in thread
From: H. Peter Anvin @ 2008-10-16  1:03 UTC (permalink / raw)
  To: Greg KH; +Cc: Linus Torvalds, linux-kernel

Greg KH wrote:
> 
> Yes, we can handle the major/minor macros in the kernel to provide a
> compatible number so that automated scripts will not break, that's not a
> big deal.
> 
> Any thoughts?
> 
> Let the bike-shedding begin!
> 

Personally I find that having a simple counter is kind of nice, simply 
because one can talk about 27, 28, 29, ... and actually be able to rely 
on it being stable.

The 2.6 prefix has clearly outlived its utility.  The easiest way to 
deal with that is of course to simply drop it, but perhaps the best 
thing to do would be to bump the major number to 3, and start out with 
3.0 instead of 2.6.28, 3.1 for 2.6.29 and so on.  This has the advantage 
that we still retain the major number for "huge changes".

On the other hand, a number of projects have gone to simple counters for 
version numbers, without a leading major.  Just having *one* number (or 
two for point releases) compensates to a large degree for the numbers 
being large.  Given that, we could just make it version 3 instead of 
2.6.28, 4 instead of 2.6.29 and so on.

	-hpa

^ permalink raw reply	[flat|nested] 111+ messages in thread

* [RFC] Kernel version numbering scheme change
@ 2008-10-16  0:25 Greg KH
  2008-10-16  1:03 ` H. Peter Anvin
                   ` (8 more replies)
  0 siblings, 9 replies; 111+ messages in thread
From: Greg KH @ 2008-10-16  0:25 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel

Hi,

You brought this topic up a few months ago, and passed it off as
something we would discuss at the kernel summit.  But that never
happened, so I figured I'd bring it up again here.

So, as someone who constantly is dealing with kernel version numbers all
the time with the -stable trees, our current numbering scheme is a pain
a times.  How about this proposal instead?

We number the kernel based on the year, and the numbers of releases we
have done this year:
	YEAR.NUMBER.MINOR_RELEASE

For example, the first release in 2009 would be called:
	2009.0.0
The second:
	2009.1.0

If we want to be a bit more "non-zero-counting" friendly: we can start
at "1" for the number:
	2009.1.0 for the first release
	2009.2.0 for the second.

Then the stable releases can increment the minor number:
	2009.1.1 for the first stable release
	2009.1.2 for the second.
	and so on.

Benefits of this is it more accuratly represents to people just how old
the kernel they are currently running is (2.6.9 would be have been
2004.9.0 on this naming scheme.)

Yes, we can handle the major/minor macros in the kernel to provide a
compatible number so that automated scripts will not break, that's not a
big deal.

Any thoughts?

Let the bike-shedding begin!

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 111+ messages in thread

end of thread, other threads:[~2008-10-22 18:13 UTC | newest]

Thread overview: 111+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-20  6:05 [RFC] Kernel version numbering scheme change Denys Fedoryshchenko
  -- strict thread matches above, loose matches on Subject: below --
2008-10-16  2:10 H. Peter Anvin
2008-10-16  0:25 Greg KH
2008-10-16  1:03 ` H. Peter Anvin
2008-10-16  1:51   ` David Sanders
2008-10-16  2:18   ` Greg KH
2008-10-16  7:02 ` Thorsten Leemhuis
2008-10-16  7:34   ` david
2008-10-18 21:44     ` Jan Engelhardt
2008-10-19  1:52       ` david
2008-10-19  2:44         ` Jan Engelhardt
2008-10-16  8:21 ` el es
2008-10-16  9:09   ` H. Peter Anvin
2008-10-16  9:33     ` el es
2008-10-16 10:05       ` el es
2008-10-16 10:14         ` Kristoffer Ericson
2008-10-16 17:30       ` david
2008-10-16  9:15 ` Hans J. Koch
2008-10-16 15:21   ` Geert Uytterhoeven
2008-10-18 21:56   ` Jan Engelhardt
2008-10-16 12:49 ` Adrian Bunk
2008-10-16 15:17   ` Greg KH
2008-10-16 15:30     ` Bill Nottingham
2008-10-16 15:47       ` Greg KH
2008-10-16 17:16         ` Adrian Bunk
2008-10-17  4:02           ` Greg KH
2008-10-17  4:26             ` Grant Coady
2008-10-17  4:53             ` Randy Dunlap
2008-10-17  9:31             ` Alan Cox
2008-10-17 16:40               ` H. Peter Anvin
2008-10-17 17:42                 ` Greg KH
2008-10-18  7:18                   ` H. Peter Anvin
2008-10-20  3:48                     ` Alexandre Oliva
2008-10-20  5:29                       ` H. Peter Anvin
2008-10-20  7:13                         ` Alexandre Oliva
2008-10-20 18:55                       ` Alex Howells
2008-10-20 20:21                         ` Greg KH
2008-10-21 19:52                           ` Alex Howells
2008-10-22  0:41                             ` Valdis.Kletnieks
2008-10-22  4:15                               ` Grant Coady
2008-10-22  8:58                               ` Alex Howells
2008-10-22  9:11                                 ` Alan Cox
2008-10-22 18:11                             ` Stefan Richter
2008-10-21 18:54                         ` Stefan Richter
2008-10-17 17:41               ` Greg KH
2008-10-17 19:45                 ` Alan Cox
2008-10-17 21:42                   ` Greg KH
2008-10-16 16:46     ` Adrian Bunk
2008-10-17  3:47       ` Greg KH
2008-10-17  6:47         ` Adrian Bunk
2008-10-17  7:55           ` Greg KH
2008-10-17  8:16             ` Steven Noonan
2008-10-17 17:46               ` Greg KH
2008-10-17 19:06                 ` Bartlomiej Zolnierkiewicz
2008-10-17 21:44                   ` Greg KH
2008-10-17 19:47                 ` Alan Cox
2008-10-17 21:44                   ` Greg KH
2008-10-17 22:14                     ` Matthias Schniedermeyer
2008-10-17 22:49                     ` Rafael J. Wysocki
2008-10-18  1:23                       ` david
2008-10-18 23:14                         ` Jiri Kosina
2008-10-19  1:50                           ` david
2008-10-19 12:51                           ` Rafael J. Wysocki
2008-10-19 16:29                             ` david
2008-10-19 17:45                               ` Rafael J. Wysocki
2008-10-19 17:47                                 ` david
2008-10-19 17:57                                   ` Rafael J. Wysocki
2008-10-18  8:45                     ` Willy Tarreau
2008-10-18 23:17                       ` Jiri Kosina
2008-10-19  3:35                         ` Willy Tarreau
2008-10-20 20:30                       ` Greg KH
2008-10-20 20:54                         ` Felipe Balbi
2008-10-20 21:06                           ` Greg KH
2008-10-20 21:58                             ` Arnd Bergmann
2008-10-20 22:24                             ` Felipe Balbi
2008-10-21 19:11                               ` Stefan Richter
2008-10-21 19:16                                 ` Felipe Balbi
2008-10-18 22:33                     ` Jan Engelhardt
2008-10-19 18:33                       ` Greg KH
2008-10-19 19:51                         ` Jan Engelhardt
2008-10-19 23:40                           ` david
2008-10-18 22:38                     ` Jan Engelhardt
2008-10-18  1:20               ` david
2008-10-18  8:32               ` Willy Tarreau
2008-10-17  8:56             ` Adrian Bunk
2008-10-17 10:06               ` Peter Zijlstra
2008-10-17 11:18                 ` Alexey Dobriyan
2008-10-17 11:26                   ` Peter Zijlstra
2008-10-17 11:32                     ` Alexey Dobriyan
2008-10-17 15:30               ` Chris Friesen
2008-10-17 17:45               ` Greg KH
2008-10-18  9:01               ` Willy Tarreau
2008-10-18 10:04                 ` Adrian Bunk
2008-10-18 11:08                   ` Willy Tarreau
2008-10-18 11:50                     ` Adrian Bunk
2008-10-18 12:28                       ` Willy Tarreau
2008-10-18 13:48                         ` Adrian Bunk
2008-10-18 14:13                           ` Willy Tarreau
2008-10-16 14:26 ` markus reichelt
2008-10-16 15:35   ` Theodore Tso
2008-10-16 18:05     ` John Stoffel
2008-10-16 19:14     ` Harald Arnesen
2008-10-17  1:53     ` Dave Young
2008-10-17  9:05       ` Jike Song
2008-10-17  9:14         ` Dave Young
2008-10-20  3:49     ` Daniel Phillips
2008-10-16 15:18 ` Geert Uytterhoeven
2008-10-17  1:26 ` Rob Landley
2008-10-17 12:46 ` Giacomo A. Catenazzi
2008-10-17 17:40   ` Greg KH
2008-10-18  1:32   ` david

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).