Date: Wed, 30 Aug 1995 21:32:13 -0600 From: Nate Williams <nate@rocky.sri.MT.net> To: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> Cc: jkh@time.cdrom.com (Jordan K. Hubbard), hackers@freebsd.org Subject: Re: /etc/disktab and stuff Message-ID: <199508310332.VAA26359@rocky.sri.MT.net> In-Reply-To: <199508310004.RAA09965@gndrsh.aac.dev.com> References: <6476.809816361@time.cdrom.com> <199508310004.RAA09965@gndrsh.aac.dev.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I don't believe I'm actually defending Jordan against Rod, since most of the time I agree with Rod but anything is possible I guess. [ sysinstall changes ] > You have now promised a boat load of ``new'' features and plan to implement > them in 2.1 is something that the decision was already made and _AGREED_ > to. Actually, I know at least some of the promised changes are already in the code. I was using -stable for building the install disk for the Thinkpad, and it is definitely different from the install I just did from the 2.0.5 CD. > b) ee is new green code, not sutible for production release, it's been > in the tree 24 hours and has had a rash of commits, not a good > canidate for release, lickely to put egg on our face. Rash of commits == 2 commits. One is to fix 8-bit mode by Andrey, the other is to add new languages to the code. Neither of the commits were bug fixes, and IF he would have committed the code with the new features in place it would have completely screwed up any new imports of the code from the original tree later. > c) Major changes to sysinstall are major changes to code, to very > critical code IMHO. Sysinstall as it stands right now is a very > known quantity, yes it has some bugs, yes it is missing some features, > but I dare say trying to cram what should be a minimum 30 day developement > effort into 3 days and doing it the 3 days before the release is the > best way I know to create a systinstall full of bugs. See above. > You had 2 months of delay to go write a better sysinstall, why is it coming > in 3 days before release? You should have no special treatment here, That's where I think you are wrong Rod. He *does* have special treatment to do anything he likes as one of the releas engineers. If he hoses up the entire release, it's his butt hanging out in the wind. > Joe blow walked up to any release team person right now and said, hey, > that whizzy wig woggler devfs code is neato nifty, would you pull it into > 2.1 we would all tell him to go jump off a cliff as it is far to green. True, but because the release engineer(s) are the FreeBSD gods, they can do anything they wish. If it breaks the tree, and wipes out hard-disks of all the machines it touches, *they* must fix the code and spend the long hours it takes to fix the tree and calm the users down. It's all nice and good to have guidelines for doing things, but when push comes to shove the rel.eng. has FINAL say on everything that goes in the the tree. No ifs, ands, or butts get in the way. (Note the intentional misspelling on the last one for a lame attempt at humor). If Jordan/David breaks the release tree, it is their responsibility to 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. 'Nuff said, Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508310332.VAA26359>