From owner-freebsd-hackers Thu Aug 31 04:37:00 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id EAA03220 for hackers-outgoing; Thu, 31 Aug 1995 04:37:00 -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 EAA03214 for ; Thu, 31 Aug 1995 04:36:56 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id EAA10989; Thu, 31 Aug 1995 04:36:21 -0700 From: "Rodney W. Grimes" Message-Id: <199508311136.EAA10989@gndrsh.aac.dev.com> Subject: Re: /etc/disktab and stuff To: nate@rocky.sri.MT.net (Nate Williams) Date: Thu, 31 Aug 1995 04:36:20 -0700 (PDT) Cc: jkh@time.cdrom.com, hackers@freebsd.org In-Reply-To: <199508310332.VAA26359@rocky.sri.MT.net> from "Nate Williams" at Aug 30, 95 09:32:13 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: 6738 Sender: hackers-owner@freebsd.org Precedence: bulk > > 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. As they say ``sh*t happens'' :-) > [ 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. I have no problem with the changes that have already gone in, most of that was done 2 months ago!!! It has been in a snap, it is of known quantity! Heck, a lot of it was done as ``2.0.6'' 3 months ago! > > 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. I haven't supped in 48 hours, so I can't check rlogs, but I seem to recall 4 commits. 4 commits in < 24 hours is a dc/dt rate unacceptable for code about to go into a production release. It has all of 2 days in the tree and will have less than 5 by the time the beta rolls. I will state one more time, code in the tree for less than 1 or 2 weeks should _NEVER_ be pulled into use in a release of software, we just don't have enough test time on it! > > 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. I am not objecting to all changes to sysinstall!! I am objecting to the fact Jordan desires to, (cant find his word for it right now), hack it to bits, as self desriben ``major work in the next 3 days'', that sudenly became ``should have it all working by 2 weeks top''. I am sorry, I have been around this for the whole 3 years, if he said 3 days to get it in, 2 weeks to getting it working, it REALLY means we will have it STABLE in 2 months! [Rod ceffecient of software developement estimates to reality is a 4.2 factor, this has been proven to be spot on by 4 releases of FreeBSD in actual vs intial promissed release dates] > > 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. That changed when it went from ``release engineer'' to ``release team'', it is now (or was until 24 hours ago) 3 butts on the line, one of them being mine. > > > 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. I disagree with that statement that they are the gods, and can do anything they wish, and perhaps it should be rewritten so that we have a ``release'' team and a ``QA'' team. QA has always been the ``gods'' about issues like this :-) > 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 ^^^^^^^^^^^^^^^^^^^^ Revised at 2.1 branch to say ``The release engineering team has FINAL say'', and per private agreements if ``any one of the release team has doubts about new code coming in it should be closly examined by formal code review before it does come in''. > 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 Jordan/David/Rod. > 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. >From Jordans already posted comprimise, it has effected his decission process, and he is willing to take what I would consider the better road and go roll things as they are (sysinstall 2.1-stable is a major improvement over 2.0.5R, not the all singing all dancing thing it is desired to be, but quite usable) > 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. The code should have been in the tree within 14 days of branching, then we would be on schedule. 2 months late, is 2 months late, things that are late get left out of releases, plain and simple. Exceptions for release engineers on this rule is simply bogus! > > 'Nuff said, I wish.. but I've been trying to pound some common sense into the minds of all of FreeBSD about what you do and don't do in a release engineering branch of a tree. It is starting to sink in, but it still has a long way to go. If people want to see the stability that was in 1.1.5.1 (a fluke chance of luck given the conditions and release methology used), and the stability that is in some commercial software it means playing by the big boy rules, and doing release engineering as it is meant to be done (please read /usr/share/doc/releng.ascii, and once you have read that a few good books on software QA and testing). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD