From owner-freebsd-hackers Fri Jun 7 04:31:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA07512 for hackers-outgoing; Fri, 7 Jun 1996 04:31:57 -0700 (PDT) Received: from DATAPLEX.NET (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA07507 for ; Fri, 7 Jun 1996 04:31:55 -0700 (PDT) Received: from 199.183.109.242 by DATAPLEX.NET with SMTP (MailShare 1.0fc5); Fri, 7 Jun 1996 06:31:25 -0600 Message-ID: Date: 7 Jun 1996 06:31:09 -0500 From: "Richard Wackerbarth" Subject: Re(2): The demise of -stable To: "FreeBSD Hackers" , "Jordan" , "p.richards@elsevier.co.uk" , "stable@freebsd.org" X-Mailer: Mail*Link PT/Internet 1.6.0 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Paul Richards writes: > The sort of bug fixes that would be OK would be the fixes Justin has made to > the adaptec driver, the sort of thing I wouldn't like to allow would be > "choice bits" since that's not what people tracking -stable are really > looking for, they want the bugs in the functionality they have fixed not > new stuff, they'll wait until the next full release for that, their main > concern is *stability*. "Jordan K. Hubbard" writes in reference to submitters for the "new" stable: > This should be handled by one or at most two people who _really want_ > -stable to live and are willing to slowly dribble patches into it. > We've already been "outsourcing" the job of producing CTM deltas for > -stable to Richard Wackerbarth, why not make all of -stable that way? I can go for that. Right now, the worst thing about -current is that it _usually_ is unstable. I have a friend who, like myself, has been in computers since the "dark ages" of 029 keypunches. His attitude is to ALWAYS wait 6 months for a new release to get really shaken out before he even considers installing it. That attitude has merits. It was my hope that FreeBSD would offer a viable alternative to BSDI. "Stable" seemed to be a big step in that direction. I would hate to see the concept dropped rather than refined. As I see it, the organization needs 3 trees at all times. 1) The latest "bleeding edge" development hack. 2) The current release-in-progress. 3) The tried-and-true production system. As a new system is being released the second time, it would become the likely replacement for 3). Both 2) and 3) require a lot more release engineering disipline than the -current folks seem to display. Since I am already heavily into supporting the existence of -stable, I'll step up to offer a bit more in the way of resources to host it if necessary. Unlike Jordan, I would encourage, but not require, developers to contribute additions such as new device drivers. Such additions would extend the viable life of the release, hopefully until an ISP would be willing to run on the next release. At that point, we would leap forward and the cycle would start over again. However, major changes should not be welcome in this tree. It ought to be viewed more as support for existing users rather than a "new features" system. Who knows, I might even advocate that "we" (stable hands) issue our own CD's. I hope it doewsn't come to that. -- Richard Wackerbarth rkw@dataplex.net -- ...computers in the future may have only 1,000 vacuum tubes and weigh only 1/2 tons. -- Popular Mechanics, March 1949