From owner-freebsd-current Sun Sep 21 18:21:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA29985 for current-outgoing; Sun, 21 Sep 1997 18:21:42 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA29979 for ; Sun, 21 Sep 1997 18:21:38 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id SAA16080; Sun, 21 Sep 1997 18:21:58 -0700 (PDT) To: Greg Lehey cc: current@FreeBSD.ORG Subject: Re: The 3.0-970920-SNAP CD has been cancelled. In-reply-to: Your message of "Mon, 22 Sep 1997 10:21:51 +0930." <19970922102151.56679@lemis.com> Date: Sun, 21 Sep 1997 18:21:58 -0700 Message-ID: <16076.874891318@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Sun, Sep 21, 1997 at 05:21:46PM -0700, Jordan K. Hubbard wrote: > > Sorry, we gave it our best shot [etc] > > > > Just FYI. Since the previous 3.0 SNAP is from May 23rd, I think we'll > > also stop selling that one and simply put the SNAPshot product line to > > sleep for awhile. > > Is this a recognition of what many of us have been suspecting, that > -CURRENT is becoming less -STABLE? Wouldn't it be time to do a bit of > thinking about how we can improve the situation? Well, while I think that we can always stand to improve our development methodologies, it's also fair to say that running things as a volunteer development effort will *always* impose certain penalties and limit what it's possible to achieve in a given time-frame. If we were a commercial software house with 30 developers working in a large office, for example, any significant release could always be preceded by a couple of weeks of ordering in pizza for the programmers and pulling late-nighters to fix bugs and do extra-aggressive regression testing in our PC test lab. Given the proper facilities and a bunch of developers with their paychecks indexed somewhat more solidly to product quality, you can accomplish a lot of things that it's just not possible to do any other way. But in any case, we don't have the luxury of that sort of development environment so there's really not much point in gritching about it. We just have to soldier on and do our best! In the case of 3.0, I think there are also some very aggressive features in the pipeline which are totally unsuitable for 2.2 and thus really have no place else to go. If we're going to get 3.0 released sometime within Q1 98, we're going to have to put these features in ASAP even if it means suffering from (hopefully) short-term instabilities and a -current which isn't a very fun place to be for awhile. My mistake was in thinking/hoping that I could make a meaningful snapshot of this progress any time before the end of the year, an error in judgment which I've now reevaluated and made appropriate adjustments to. I also think that most folks don't really appreciate how long 2.2 has left to run. If it's anything like our previous branch, it has around 12 more months to run before we can retire it in good conscience and that means that for a large number of folks, 3.0 won't even be remotely _relevant_ until sometime in late 1998 (the point at which it reaches "stability"). I think that gives us a little time to sort these problems out. ;) Jordan