From owner-freebsd-hackers Thu Aug 31 04:52:26 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id EAA03634 for hackers-outgoing; Thu, 31 Aug 1995 04:52:26 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id EAA03628 for ; Thu, 31 Aug 1995 04:52:24 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id EAA11028; Thu, 31 Aug 1995 04:51:53 -0700 From: "Rodney W. Grimes" Message-Id: <199508311151.EAA11028@gndrsh.aac.dev.com> Subject: Re: /etc/disktab and stuff To: davidg@Root.COM Date: Thu, 31 Aug 1995 04:51:53 -0700 (PDT) Cc: nate@rocky.sri.MT.net, hackers@freebsd.org In-Reply-To: <199508310358.UAA20539@corbin.Root.COM> from "David Greenman" at Aug 30, 95 08:58:21 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4219 Sender: hackers-owner@freebsd.org Precedence: bulk > > (Jordan said:) > >Funny. Someone, who's name I'll refrain from mentioning here, was > >just musing to me the other day that maybe we should just SKIP 2.1 and > >go to 2.2.. :-) > > That was me. I was joking of course, but there was a small element of > truth. You even mentioned it to me on the phone the other night :-). > (Nate said:) > >clean it up. If the FreeBSD 2.1 release sucks the big one, then it > >sucks the big one. Hollering at them isn't going to change their mind > >about what they are doing. We've all been doing this long enough to > >know the consequences of bad decisions. > > > >Finally, what is coming up is *NOT* the 2.1 release, but a 2.1-SNAP. > >I'd rather see the code in the tree so it can be tested in the SNAP for > >a longer period of time than to see if take 30 more days to get in and > >have a crappy install for 2.1. > > Yes, and I apologize for the 2.1 tree brokeness that Rod has complained > about. This is the product of a large amount of effort to get all the changes > in before the snapshot. It's very important that as many changes as possible > that we want to be in the release be in the next snapshot. We are trying to > get this release out the door, and dribbling in the changes will only delay > it by months more. And these are changes for 96% of the cases that have been in -current for > 2 weeks, and _are_ bug fixes, not new code. I know of 1 ``new'' binary coming in, and that in ndc from the bind distribution, which was really part of the upgrade/bugfix for named/bind. I know this to be the only one as David failed to do the cvs tag operations to bring it over and I am about to go do them. Other than that he has been commiting bug fix deltas to existing code. > ...and I'm still not done yet. I have to finish up the userland and then > return to merging kernel stuff. There are a pile of important fixes in > -current that must be in the release, and I haven't hardly touched the 2.1 > kernel yet. :-) > Anyway, I have too much to do and no time to argue about this. I intend to > strike a balance between stability, features, and release schedule. The > emphasis will be on stability, followed by release schedule, and features > last. I will make an effort to bring in improvements (fixes or features) if I > think they would make 2.1 a better release...so to those who want 2.1 to be a > release with "meat", don't worry, it'll will be plenty "meaty". :-) And he has conferred with the other release team members on bringing major chunks of meat over before doing so. He talked to me about sendmail and bind before that was done, as he was unclear on the status of them and if he should bring those changes over. This is operating as a team, with at least a sanity check before code drops into the release branch. This is how release team work should be occuring. This is the first time in the history of FreeBSD that sanity checks are being done on code going into a release. I would hate to see this fall apart due to allowing Jordan to run rampent in the release branch and add new tools, and new functionality that David and myself have been so carefull about watching out for. David did one hell of a lot of work to bring in the changes he did, that means he looked at and evaluated each one before doing so, and at least let the bits sit and cure for a few weeks in -current before just splatting them into the release. I am affraid a ``reworking'' of sysinstall would not benifit from such a formal review, and now is not the time to start looking at doing one anyway as the code has not rippened in any form. Had Jordan commited this weeks ago into stable I would not have batted an eye. But coming out in 1 mail message and saying that a) we are going to roll beta in 3 or 4 days, and b) I have major changes to sysinstall before we roll beta makes my stomach CHURN and my head POUND at the idea of it. I can state rather plainly, that if this does occur it _WILL_ be additional delay in the snap shot, and additional delay in the release cycle. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD