Re: New dev model (was [PATCH] delete devfs)

From: Ben Hoskings (ben_at_jeeves.gotdns.org)
Date: 07/26/04

  • Next message: Bernd Eckenfels: "Re: clearing filesystem cache for I/O benchmarks" 
    To: linux-kernel@vger.kernel.org
Date:	Mon, 26 Jul 2004 11:38:55 +1000

    On Fri, 23 Jul 2004 09:01, Andrew Morton wrote:
    > Well. We'll see. 2.6 is becoming stabler, despite the fact that we're
    > adding features.
    >
    > I wouldn't be averse to releasing a 2.6.20.1 which is purely stability
    > fixes against 2.6.20 if there is demand for it. Anyone who really cares
    > about stability of kernel.org kernels won't be deploying 2.6.20 within a
    > few weeks of its release anyway, so by the time they doodle over to
    > kernel.org they'll find 2.6.20.2 or whatever.

    I'd like to throw my opinion into the discussion at this point too, for what
    it's worth.

    I think the idea of forking off certain releases in the 2.6.x.0 form, to only
    recieve bugfixes and security updates, is a very good idea. A couple of
    points against it were raised above, but I think if it were approached the
    right way, they wouldn't be issues.

    There wouldn't be a huge maintenance overhead, as

      -- The forks would only need to happen occasionally. When 2.6.y has advanced
    past 2.6.x (y > x) sufficiently (i.e. it has significant new functionality)
    and it has been released for sufficient time to iron out obvious bugs, then
    if it comes to be considered a particularly stable release, it would be a
    good candidate for freezing at 2.6.y.0. I would think this sort of thing
    would probably only need to happen once or maybe twice per every ten or so
    traditional releases.

      -- The only maintenance that would be needed on these frozen versions would
    be a backport of any critical bugfixes / security issues, when they occur.

    The table on the front page at kernel.org could be augmented with an extra
    row, showing the most recent frozen release from the stable tree. Users who
    want a recent _vanilla_ kernel that is unchanging and hopfully highly stable,
    could choose it.

    On Sat, 24 Jul 2004 06:57, Timothy Miller wrote:
    > Does that mean that 2.6.21 and 2.6.20.1 are two separate forks of
    > 2.6.20, one for development, and the other for stability?
    >
    > How is this fundamentally different from how it was done before with
    > odd/even minor numbers?

    IMO the process wouldn't mirror the old 2.x / 2.y model because it is much
    more fine-grained. With the old model, changes have to be backported to a
    kernel that is significantly older, and which potentially has seen
    fundamental changes in the releases between (i mean between 2.x -> 2.y). With
    the new model, a release 'freeze' could be made whenever deemed necessary,
    and since it will be a lot closer on the timeline to where the main
    development is happening, backporting the critical stuff should be a lot less
    of a headache.

    The important part would be to not go overboard with release freezing, so
    there wouldn't be 10 frozen kernels to backport to. _That_ would be a
    headache.

    There's my $0.02. :) 

    -- 
	Ben
-
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/
  • Next message: Bernd Eckenfels: "Re: clearing filesystem cache for I/O benchmarks"

    Relevant Pages

    • Re: Microsoft AntiSpyware Beta
      ... much less stability issues. ... Your experience is a rare exception. ... > Microsoft AntiSpyware beta was mentioned here by several other posters as ... > I don't intend to waste anymore time on it until it is a stabler, ...
      (microsoft.public.windowsxp.customize)
    • Re: Microsoft AntiSpyware Beta
      ... > If you visited the newsgroup I suggested, you would find it is stable. ... > I have had no problems, much less stability issues. ... >> I don't intend to waste anymore time on it until it is a stabler, ... >> DSH ...
      (microsoft.public.windowsxp.customize)