Re: RFC: Starting a stable kernel series off the 2.6 kernel

[Horst von Brand <vonbrand@inf.utfsm.cl>]

Steven Rostedt <rostedt@goodmis.org> wrote:
> On Tue, 6 Dec 2005, Florian Weimer wrote:
> > > Actually, they are already maintaining 2.6.x.y, (x => 11, 12, ...)

> > I think the 2.6.x.y series is no longer maintained once 2.6.x+1 has
> > been released for some time (surely after 2.6.x+2).

> The same can still go for this, but instead of stopping at 2.6.x+2 we could
> stop at 2.6.x+6 (or +5), and just not care about 2.6.x+[1-4].  But that
> would be strong enough for those that would like the stable branch to
> maintain it themselves.  Currently it'l hard to pick a 2.6.x that you want
> to stay with since the 2.6.x.y is stopped right after 2.6.x+1 is out.  But
> if not all 2.6.x has a .y, then that would focus more distrobutions or
> whatever to pick the same one to support.

OK, let's step back and...

- People work on Linux (or whatever other stuff) because it is /fun/ and
  /exciting/. 
- People who don't actively work on a piece of code won't know it
  intimately, so they'll make mistakes when looking for bugs/fixes
- There is little excitement in just fixing bugs in frozen code, developers
  will just migrate elsewhere if there is no fun here

- "Experimental versions" are only run by masochists and bored people who
  need fireworks now and then to know they are still alive. End users don't
  even consider them, when the software is stable enough for the crazier
  ones to unleash on the world as "stable" is when the bugs surface
  (Remember the disaster of the early 2.4s? Ever heard of "Let's wait for
  X.<even>.10 or so, by then it will be stable enough for everyday use"?).
- End users /don't/ test "prereleases", they deem them too risky... so the
  "releases" usually ship with lethal bugs for some people. Decreeing that
  each 5th (or whatever) release will be "golden" will just get people to
  skip all the others, resulting in /much more/ serious bugs in the end

- Backporting new features into a different setting is almost as hard, or
  perhaps much harder, than developing said features in the first place.
  Backpòrting bug fixes is a thankless job.
- Distributions /do/ have the infrastructure in place to collect bug
  reports and correlate them with hardware and software configurations,
  moreover they work with /one/ (or at most a few) kernel configuration,
  not with the almost random assortment of kernel configurations you'll
  find with self-built ones. They also have the (paid) manpower to extract
  conclusions from the above data. 
- If all distributions work from approximately the same base, much
  duplicate/wasted work (yes, backporting is mostly wasted effort IMHO) is
  saved.

- Tools for kernel work are /much/ better now, it is reasonable to maintain
  patches out-of-vanilla and keep the base syncronized with the standard
  kernel source. Lots of people do so now, when it previously was a
  full-time job for the incredibly productive gnome community known
  collectively as "Alan Cox" to do so. There is thus much less need for
  "odd" series in which to integrate new stuff.

All of the above led to the current kernel development model. Users might
not be too happy about it, but the key developers are. And the important
people, the ones you /have/ to keep happy in the OSS development model,
aren't the users. Besides, everybody moaning about the new development
model want something impossible: Fast development, timely integration of
support for newest hardware, while bug free all the time. Won't ever
happen.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
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/