Re: RFD: Kernel release numbering

[Andrew Morton]

Andrea Arcangeli <andrea@xxxxxxx> wrote:
>
> On Thu, Mar 03, 2005 at 03:17:52PM -0800, Andrew Morton wrote:
> > That's the only way it _can_ work.  The maintainer of 2.6.x.y shouldn't be
> 
> Andrew, what about my suggestion of shifting left x.y of 8 bits? ;) Do
> we risk the magic 2.7 number to get us stuck in unstable mode for 2
> years instead of 2 months? Doesn't 2.6.x.y pose the same risk but
> by also breaking the numbering and the stable kernel identification for
> no good reason? (ignoring the "2.6." part that carries no useful info
> anymore ;)

I think this is all a bit of a storm in a teacup, really.

2.6.x is making good progress but there have been a handful of prominent
regressions which seem to be making people think that the whole process is
bust.  I don't believe that this has been proven yet.

There is still potential to make good improvements to the existing
processes, and the main way of doing this is for the various subsystems to
be a bit more disciplined.  That means:

a) Have all your 2.6.n stuff ready to go when 2.6.n-1 is released.

b) Merge your 2.6.n stuff promptly - within two weeks of the 2.6.n-1 release.

c) Then, keep your sticky paws off it.  New development and
   not-completely-trustworthy development goes into your subsystem tree and
   Linus's tree just gets bugfixes.

That's how it _should_ work, and I'm not sure that we're sufficiently close
to it now.

Or, to put it another way, we're getting a small number of irritating
regressions, mainly in device drivers which is giving the whole thing a bad
rep.  Is there some way in which we can fix that problem without
reinventing the whole world?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/