Date: Thu, 20 Apr 95 11:27:26 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: <9504201727.AA25462@cs.weber.edu> In-Reply-To: <199504200413.AAA05141@starkhome.cs.sunysb.edu> from "Gene Stark" at Apr 20, 95 00:13:20 am
next in thread | previous in thread | raw e-mail | index | archive | help
OK, this is serious stuff which I think bears on basic philosophy (actually a hell of a lot more basic than the NetBSD vs. FreeBSD crap). Because of this, I'm going to use words that mean exactly what I want to say, so I appologize in advance to the non-native English speakers that I'm probably going to be sending scrambling to their dictionaries. > I can understand the pressures from WC to get a decent update of their > product, but so far the releases have all followed the pattern of > a flurry of stuff going into the system, followed by a an extremely > foreshortened test phase (hardly enough time for most of us to even > do a build world), followed by production of a CD-ROM. I would really > hate to see this pattern produce another CD-ROM similar to the 2.0 version. This is indeed an issue. One of overzealous engineers. > Perhaps this idea is a bit radical, but I think it would be beneficial > to separate the technical development goals of FreeBSD from the pressures > to get a CD to market. A method I have been applying to get decent > snapshots to use is to build the world regularly, observing the general > stability of the system and reading the mailing lists to assess the > frequency of changes to key portions of the system. When the frequency > of key source changes appears to have reached a local minimum and the > number of serious instability reports seems small, I try to roll a > snapshot. > > Perhaps the right thing to do would be to set an approximate target date, > then charge the release engineer with the task of monitoring the source > changes as I described above. When a decent snapshot is obtained near > the target date, it can then be subjected to beta testing for two or three > weeks to fix the most serious bugs, after which a CD can be mastered. > Other than the fact that the approximate target date is known in advance, > the release engineer need not inform anyone before the snapshot is rolled. > Indeed, this would likely promote last minute bugs. The release engineer > would then have to be careful to accept only solid bug fixes during > the beta phase. This is surely not the way to resolve the issue. Having been a commercial release engineer (in growing a company from 2 employees to 24 employees, one wears *many* hats), I can say that there *must* be a coupling between release engineering and feature engineering. The above plan would, I think, result in many more "fixed in current" or "just download current" responses to problems: this is precisely the problem with the 2.0 release. Let it be forever noted that 2.0 was an exception. It was a rush job that was done to appease legal requirements and to keep the FreeBSD efforts afloat at the same time avoiding legal action by USL. It had the nice side effect of resolving the legal issues for Walnut Creek at the same time, which can only be a good thing, given the backing they have provided. It was not the result of problems endemic to a release process. The main issue that has been a problem with the release process for me in the past has been the desire of engineers see their babies go out to a grateful public as quickly as possible. In this, it is the release engineers job to dictate a feature freeze at some point prior to the actual "ship date" (I will explain quoting this in a minute) such that an adequate beta cycle and critical bug fixing can take place. In other words, it is the release engineers job to stand in the way of feature creep too close to a release date. I think the thing that is so often misunderstood is that it is not absolutely necessary to jam all the latest developing technologies that you have into a product. You *can* and *should* save those that are immature for later releases. The date push out that has occurred so far on 2.1 that has made the consideration of 2.0.5 even conscionable at all is probably to be blamed on the addition of the slice code (among other things), which is a significant enough change that it requires a longer beta cycle. More simply, it's probably bad that it was included because it was not ready to include by the time a feature freeze should have occurred. Please do not confuse this; the fact is that I think the code is *critical* to the future of FreeBSD. It was just not ready to be included. Let's resolve to consider the releases as something *desirable to the FreeBSD group as a whole*. I think that people are forgetting this; not to pick on anyone in particular (sorry, but you brought it up so I will use you as an example), but the message above is an indication that some people are on the verge of forgetting this. FreeBSD is released *for* FreeBSD, and regular intervals for the releases are a Good Thing(tm). The regular releases are *NOT* the result of pressure by Walnut Creek to bend some more desirable release schedule to their will. (Here's the explanation of "ship date") That Walnut Creek CDROM has a ship date for their product, and that this happens to be related to a release engineering cycle being completed on a CDROM means that it is loosely coupled to FreeBSD's "ship date" (since the packaging into an installable format must occur after the code is ready to be installed). So what is being confused here is the fact that with or without Walnut Creek CDROM involved, FreeBSD should be making and *keeping* a regular release schedule (whether this is offset from purely yearly quarters to avoid vacations, etc. is another matter, and one that *does* bear discussion). I think that Walnut Creek, of course, "gets first dibs" on making the resulting code into a CDROM and selling it commercially because their people are involved in the project, and their equipment is under the project. Note that there is no formal arrangement, and this is an issue of timing; it happens that Walut Creek is a project "insider", and so has an advantage over those who are not. BUT THE IDEA THAT THEY ARE ADVERSELY INFLUINCING FREEBSD BY IMPOSING A SCHEDULE THAT WOULD NOT OTHERWISE BE IMPOSED ANYWAY IS WRONG. So lets return to the internal feature freeze dates, and the internal release engineering that is associated with them, and leave Walnut Creek out it as a topic of the discussion. There have to be regular releases. This is one of the benefits of FreeBSD. This means that there will have to be freeze dates to allow for an adequate beta cycle, and it also means that there will (inevitably) be rushes to "get code in under the wire". And that's just the way it is. Far from retarding the developement process, I think the rush of extra effort around freeze dates does not represent the normal level of developement effort taking place -- it represents a higher level of effort, as people strain to get their babies in under the wire. It is a Good Thing(tm). Yes, this results in "premature babies"... that's what the beta cycle is there for. It is a safety net, and the release engineer is the guy who mans the net. 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?9504201727.AA25462>