Re: Definitions: from LKML FAQ

From: Michael Rothwell (rothwell@office.ilan.net)
Date: Wed Aug 09 2000 - 22:13:53 EST


http://www.tux.org/lkml/#s1-8

8.What is a feature freeze?
              
(ADB) A feature freeze is when Linus announces on the linux-kernel list
that he will not consider any more features until the release of a new
stable kernel version. Usually the net effect of such an announcement is
that on the following days people on the list propose a flurry of new
features before Linus really enforces the feature freeze. ;-)

9.What is a code freeze?

(ADB) A code freeze is more restrictive than a feature freeze; it means
only severe bug fixes are accepted. This is a short phase that usually precedes the
creation of a new stable kernel tree.

... based on this. I would say that Linux has been in an unenforced
"feature freeze" for about a year, but has not yet entered a "code
freeze," despite being in "2.4.0-test-X" stage for months, and
"2.3.99-pre-X" for nearly a year.

Perhaps the real problem isn't the "feature freeze" but the numbering --
maybe we should still be in the "2.3.xxx" pre-nothing stage currently. Or
the FAQ needs to be updated.

-Michael

You said...

> I dont think there is a simple answer
>
> Clear bug fixes
>
> o if I do this it crashes the kernel. This patch stops it
> o if I do this it violates the standard
>
>
> Clearly new stuff
>
> o New file system
> o Rewriting the VM
> o Adding all the flash device support
>
>
> Now of the new there are three categories:
>
> 1. A driver or file system or protocol stack using existing
> interfaces that
> makes no change to the rest of the kernel. If turning the module
> otpion
> off gives a kernel that has no changes then this is good.
>
> These kind of things can be added almost any time as they dont
> impact
> stability for anyone else and a bad driver is generally better
> than
> no support
>
> 2. Stuff that tweaks internals a bit (extreme case rewriting the
> VM).
> You get it wrong and everyone gets crashes. Has to be done with
> care
> well tested and preferably earlier in the cycle
>
> 3. Changing the interfaces themselves and breaking all drivers or
> all
> file systems. This should be done early. Some of Al Viro's stuff
> was late (but probably wise in the long term) and this caused a
> fair
> bit of friction
>
> Alan
>
>
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:20 EST