From owner-freebsd-hackers Wed Oct 16 11:15:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA22549 for hackers-outgoing; Wed, 16 Oct 1996 11:15:45 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA22540 for ; Wed, 16 Oct 1996 11:15:43 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA03254; Wed, 16 Oct 1996 11:14:01 -0700 From: Terry Lambert Message-Id: <199610161814.LAA03254@phaeton.artisoft.com> Subject: Re: IP bugs in FreeBSD 2.1.5 To: jdw@wwwi.com (Jeffrey D. Wheelhouse) Date: Wed, 16 Oct 1996 11:14:01 -0700 (MST) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <199610160307.UAA23003@wwwi.com> from "Jeffrey D. Wheelhouse" at Oct 15, 96 08:07:32 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > That divergance is exactly the problem I am trying to point out. > Already three "significant contributors" people have said that > -stable isn't worth the trouble. However, stable is the only choice > for people who want a stable OS who don't have a lot of time to > invest in sanitizing their own private -current. > > >So... I would rather see a 2.2R that was, perhaps, a bit rough at the > >edges (like 2.0R) sooner rather than later. > > I agree. If -stable has abandoned, it's time to look toward something > new. Based on the assertions that several people have made that > "current is usually fairly stable," it seems like the benefits of > this might far outweigh the effort, or at least the possibility is > real enough to discuss. I think you are missing the answer: Stable gets to be called stable after bunches of people have tested a release candidate. Bunches of people are not willing to test an interim release when something newer is available. Stable has not been abandoned. When current is code cut as a release candidate and is deemed to be sufficient stable to be called stable, then there will be a new stable. So it comes down to: Do you want it to be stable? Or do you want people to make bug fixes to it, potentially rendering it unstable? You can't have both. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.