Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Apr 1995 17:17:46 -0400
From:      Gene Stark <gene@starkhome.cs.sunysb.edu>
To:        cs.weber.edu!terry@sbstark.cs.sunysb.edu
Cc:        FreeBSD.org!hackers@sbstark.cs.sunysb.edu
Subject:   Minutes of the Thursday, April 13th core team meeting in Berkeley.
Message-ID:  <199504202117.RAA08208@starkhome.cs.sunysb.edu>
In-Reply-To: Terry Lambert's message of Thu, 20 Apr 95 11:27:26 MDT <9504201727.AA25462@cs.weber.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
>   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.

This seems logical to me.

>   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.

Agreed.

>   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.

OK.

>   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.

Hmm.  I don't have access to the communications between the core group,
but it seemed pretty clear to me that the accelerated release of 2.0
was due to "Holy shit!  Jordan's leaving for Europe and WC *really needs*
to be able to process all it's backorders by Xmas.  Let's skip the
beta phase and get something out yesterday.  I don't think the result
was particularly beneficial to FreeBSD's image as a stable system,
and I personally have trouble recommending that somebody buy that particular
CD-ROM.

>   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 don't have a problem with this.

>   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.

As I have said, this is not how it appears to me.  I don't think anybody
is doing this on purpose, but I think that is what is happening.

   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.


>   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.

This is fine, let's not succumb to whatever pressures have been making
it otherwise in the past.

							- Gene



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504202117.RAA08208>