This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Tue May 21 03:30:48 2024 Received: from nic.funet.fi (nic.funet.fi [193.166.0.145]) by herbie.ucs.indiana.edu (8.10.1/8.10.1) with ESMTP id e7A3Q0t04183 for ; Wed, 9 Aug 2000 22:26:01 -0500 (EST) Received: from vger.rutgers.edu ([128.6.190.2]:20218 "EHLO vger.rutgers.edu" ident: "NO-IDENT-SERVICE[2]" smtp-auth: TLS-CIPHER: ) by nic.funet.fi with ESMTP id ; Thu, 10 Aug 2000 06:24:53 +0300 Received: (majordomo@vger.rutgers.edu) by vger.rutgers.edu via listexpand id ; Wed, 9 Aug 2000 22:54:12 -0400 Received: by vger.rutgers.edu id ; Wed, 9 Aug 2000 22:53:54 -0400 Received: from office.ilan.net ([216.27.3.20]:4175 "EHLO office.ilan.net") by vger.rutgers.edu with ESMTP id ; Wed, 9 Aug 2000 22:53:31 -0400 Received: from gromit.house (cvs.rd.ilan.net [216.27.3.8]) by office.ilan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QQQZ4736; Wed, 9 Aug 2000 23:22:31 -0400 Date: Wed, 9 Aug 2000 23:19:07 -0400 (EDT) From: Michael Rothwell X-Sender: rothwell@gromit.house To: linux-kernel@vger.rutgers.edu Subject: Undeliverable: Re: Definitions: from LKML FAQ (fwd) Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/Mixed; boundary="----_=_NextPart_000_01C00279.96EFC72E" Content-ID: Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ------_=_NextPart_000_01C00279.96EFC72E Content-Type: TEXT/PLAIN; charset=US-ASCII Content-ID: Alan, are you really filtering email from me, or is this simply the third random mailer error that I've gotten today? :) It's not like I've ever been insulting on the LKML -- I hardly ever post. Or is our whole domain denied due to earlier posts by Zappe? Wassup? -M ---------- Forwarded message ---------- Date: Wed, 9 Aug 2000 23:17:58 -0400 From: System Administrator To: Michael Rothwell Subject: Undeliverable: Re: Definitions: from LKML FAQ Your message To: Alan Cox Cc: linux-kernel@vger.rutgers.edu; zapman@interlan.net Subject: Re: Definitions: from LKML FAQ Sent: Wed, 9 Aug 2000 23:13:53 -0400 did not reach the following recipient(s): Alan Cox on Wed, 9 Aug 2000 23:17:58 -0400 The recipient name is not recognized The MTS-ID of the original message is: c=US;a= ;p=InterLan Technol;l=OFFICE0008100317QQQZ473V MSEXCH:IMS:InterLan Technologies:ILAN:OFFICE 3550 (000B099C) 550 rejected: administrative prohibition ------_=_NextPart_000_01C00279.96EFC72E Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII Content-ID: Content-Description: Message-ID: From: Michael Rothwell To: Alan Cox Cc: linux-kernel@vger.rutgers.edu, zapman@interlan.net Subject: Re: Definitions: from LKML FAQ Date: Wed, 9 Aug 2000 23:13:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 > > > > > ------_=_NextPart_000_01C00279.96EFC72E-- - 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/