Date: Thu, 20 Apr 95 16:02:29 MDT From: terry@cs.weber.edu (Terry Lambert) To: gene@starkhome.cs.sunysb.edu (Gene Stark) Cc: hackers@FreeBSD.org Subject: Re: Minutes of the Thursday, April 13th core team meeting in Berkeley. Message-ID: <9504202202.AA28852@cs.weber.edu> In-Reply-To: <199504202110.RAA08175@starkhome.cs.sunysb.edu> from "Gene Stark" at Apr 20, 95 05:10:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >It was not the result of problems endemic to a release process. > > I disagree with this, as the prior release that was burned into CD-ROM > (1.1) IMHO was also an inferior release due to a rushed testing phase. > Release 1.1.5.1, which is the best release to date, was essentially the > result of testing and bug fixes applied to 1.1. Let me clarify the term "endemic". I do not believe that it is an inevitable outcome of the release process as it is defined. In other words, it is a result of failure of process rather than the process itself. It's not a question of procedure, it's a question of failure to follow procedure. > Every time the beta phase of a release has been shrunk to zero, I have > complained. I usually see everyone say "I'll *never* allow this to happen > again," but by the time the of the next release, the same thing has > happened again. It is my impression that the same thing is happening > right now with 2.0.5. A shrinking beta phase is a violation of the release protocol as it has been agreed to. The unpleasent part of release engineering is in being the source tree hall monitor -- enforcing protocol. > My feeling is that a system version from approximately April 7 would be > a good one to use as a base for 2.0.5. Check out that release, put it > out for beta test, integrate bug fixes only, and burn it into the CD-ROM. This is a good rollback date (at least as good as any other) to pick as the code freeze date after which new features will not be introduced to the release branch. I'm sure, though, that Paul (or whoever has replaced him as release engineer) has already branched the code at what looked like a logical breakpoint. As long as a branching has taken place, it's really not kosher to second guess him unless we are willing to walk a mile in his shoes. I would like to see release packaging polished to the point that a beta release can be rolled from a full install machine by typing "make release" somewhere so that we can get an immediate feel for beta (or so that those of us with extra machines can incrementally test and source tree that fully builds). This is an unreasonable requirement to have at this time without the support already in place, but it is certainly a topic that should be taken up in the near future. Unfortunately, a lot of what takes place in an install is still hand massaged, which means that there is a terrific investment in the people doing the work instead of in tools to do the work automatically -- this leaves the process particularly susceptable to disruption by distraction of the people or the people being hit by a bus, or snipers from The Forces of DOS taking them out. I think that many of the complaints that you have are valid relative to 2.0, but that they are indicative of failure to follow procedure more than anything else. Hopefully, they will be proven invalid for the next and subsequent releases, which are not under the shadow of exceptional circumstances (USL, etc) that 2.0 labored under. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504202202.AA28852>