Messages in this thread | | | Date | Wed, 9 Aug 2000 23:13:53 -0400 (EDT) | From | Michael Rothwell <> | Subject | Re: Definitions: from LKML FAQ |
| |
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/
| |