From owner-freebsd-hackers  Wed Apr 19 21:14:28 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id VAA14338
          for hackers-outgoing; Wed, 19 Apr 1995 21:14:28 -0700
Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA14332
          for <hackers@freebsd.org>; Wed, 19 Apr 1995 21:14:26 -0700
Received: (from root@localhost) by sbstark.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id AAA02990 for hackers@freebsd.org; Thu, 20 Apr 1995 00:14:15 -0400
Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.6.11/8.6.9) id AAA05141; Thu, 20 Apr 1995 00:13:20 -0400
Date: Thu, 20 Apr 1995 00:13:20 -0400
From: Gene Stark <gene@starkhome.cs.sunysb.edu>
Message-Id: <199504200413.AAA05141@starkhome.cs.sunysb.edu>
To: hackers@FreeBSD.org
Subject: Re: Minutes of the Thursday, April 13th core team meeting in Berkeley.
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

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.

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.

The above strategy would hopefully keep WC supplied with a decent product,
without adversely impacting the desire for new features to be included
in the system.

							- Gene Stark