From owner-freebsd-hackers  Wed Apr 19 19:20:14 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id TAA09217
          for hackers-outgoing; Wed, 19 Apr 1995 19:20:14 -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 TAA09211
          for <hackers@freebsd.org>; Wed, 19 Apr 1995 19:20:08 -0700
Received: by genesis.tiac.net (8.6.9/genesis0.0)
	id WAA17794; Wed, 19 Apr 1995 22:20:04 -0400
Date: Wed, 19 Apr 1995 22:20:04 -0400
From: steve2@genesis.tiac.net (Steve Gerakines)
Message-Id: <199504200220.WAA17794@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

> 	April 17th:	Begin CODE 'FREEZE' on NEW features on a branch copy
> 			of 2.0-950412-SNAP.
> 
> 	April 21:	SNAPSHOT for testing.
> 
> 	April 24th:	2.0.5 CDROM mastered.

Ugh!  This sounds awefully familar.  I'm not a core member, but how about
this as a thought:

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.

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

- Steve
steve2@genesis.tiac.net