From owner-freebsd-hackers  Thu Apr 20 17:41:38 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id RAA17163
          for hackers-outgoing; Thu, 20 Apr 1995 17:41:38 -0700
Received: from genesis.tiac.net (genesis.tiac.net [204.180.76.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA17151
          for <hackers@freebsd.org>; Thu, 20 Apr 1995 17:41:27 -0700
Received: by genesis.tiac.net (8.6.9/genesis0.0)
	id UAA01973; Thu, 20 Apr 1995 20:41:21 -0400
Date: Thu, 20 Apr 1995 20:41:21 -0400
From: steve2@genesis.tiac.net (Steve Gerakines)
Message-Id: <199504210041.UAA01973@genesis.tiac.net>
To: hackers@FreeBSD.org
Subject: Re: Minutes of the Thursday, April 13th core team meeting in Berkeley.
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> > If you must stick to a strict timetable, why not start automatically
> > imposing a feature freeze 3 weeks before the close of each quarter.  At
> > least if it was regularly scheduled we could all see it coming.  Circle
> > the burn date in red on your calendar.  :-)  Only generate *one* SNAP
> > release mid way through the quarter.  At least this would reduce the
> > number of moving targets.

> Absolutely, positively, no releases on a quarter boundary.  Please.
> 
> Both work and major holidays (end of June and end of December) cause
> big crunches and too many FreeBSD contributers have "day jobs".

> FreeBSD "quarters" should be shifted one way or another by a month.

Of course.  When I say quarters I'm talking about three month intervals,
not necessarily calendar quarters.  It wouldn't make much sense to
release a product *after* christmas.  :-)

> > I'm not trying to be critical, but I really like FreeBSD.  I think it'd
> > do nothing but hurt FreeBSD's reputation if the trend of surprise
> > releases continues.  Right now there are so many different releases
> > floating around it's getting very difficult to support.  (Older snaps
> > are gone but people sure are still using them.)

> Snaps aren't releases and won't go away.  The NEED to use snaps is at
> least part due to 2.0 problems that a bug fix release would take care
> of.

I think interim releases are fine so long as they are  regularly timed.
I just believe if particular dates are pre-determined for releases or
interim releases it makes life easier to work toward a stability goal.
Granted not all goals can be met by fixed dates but at least the playing
field is defined.

- Steve
steve2@genesis.tiac.net