Date: Wed, 30 Aug 1995 17:04:31 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: hackers@freebsd.org Subject: Re: /etc/disktab and stuff Message-ID: <199508310004.RAA09965@gndrsh.aac.dev.com> In-Reply-To: <6476.809816361@time.cdrom.com> from "Jordan K. Hubbard" at Aug 30, 95 01:59:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> [Went for a walk.. it often helps... :-)] > > Take off your engineering hat, put on the shipping hat and kick the > > thing out the door. I have not seen the code commits to make > > sysinstall ``substatially different'' and the next 72 hours is not > > the time to make it that way. > > Sigh... I'm responsible for this piece of technology, Rod, and it > will meet my standards before I release it. Period. That is correct, you are responsible for that piece of technology, and you should not release it to anyplace until it meets your standards. I am saying that it does not meet the standards of the release criteria, and therefore becomes a 2.2 functional addition, not one to 2.1. We have been over this ground and it was agreed, no new functionality. 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. This is a recuring theme, and yes, I am tearing you a new asshole over it, no that is not good for the project, so let try to reword this. a) When 2.1 was branched and the ``release team'' formed by a document I wrote at your request, reviewed and approved by both David and yourself for publication on both the -core team list for 1 round of reviews, and then to -current as publication I was under the firm impression that i) code going into 2.1 was to have at least 1 formal review by someone before being brought over. David would have all final says in kernel issues and ii) no new functionality of _ANY_ kind was to be added to this branch, it was to be a bugfix against 2.0.5. And David has already affirmed my view on this by saying things should go into -current and stew for at least a week or two before going over (though he himself has broken this concept 3 or 4 times in the last few days). 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. 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. Of all people I though you had come to learn this by now, but evidently you desire to do it one more time. Well, since I have (now had) a voice in what went on the release branch for 2.1 as a release team member, I am voicing my opinion that I think this is a bad thing to be doing right now. > I'm not even > going to argue about it with you, I'm just going to go back to work. > Anybody thinks they can do it better and faster, they're more than > free to jump at it! I don't want it done ``better and faster'' for 2.1, I want it done slow and correct for 2.2. We have known quantity and quality code with sysinstall now document the hell out of the bugs, fix the clear cut ones (even gotta be very carefull doing that or you add one while removing one :-() 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, if 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. Well, your code is not even in the tree yet, so, ``go jump off a cliff'' :-) :-) :-) NOTE SMILEYS.. I think you get my drift. > > > majority vote of the release team, but right now I am standing here looking > > at the 4th day of failed make worlds in -stable and am starting to get > > rather PISSED about it. > > That's a different problem and I think that I'm getting unfair abuse > because of it. You're spreading vinegar instead of honey again, and > this little fly isn't having any of it. Your right, it is a different problem. And your about to watch me go code smashing through -stable to fix it as I need it building at all times, and that was clearly stated as an objective. We are humans, errors are made, and I need to address my ``pissed'' state on that issue with the correct person and try to find a modous oparandi and or paradigm that prevents it from occuring again when we get close to the 2.1 release code cut as I surely do not want to see another 30k line diff go in 3 days before a code cut anyplace, weither that be FreeBSD or HP-UX or Solaris, it's just a really foolish thing to do in the world of software release and quality. Perhaps I should dig out a few of the papers I have on these issues and shove them in the right mail slots :-) :-). I'll shove one in there now.. /usr/share/doc/releng.ascii... -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508310004.RAA09965>