Date: Thu, 20 Apr 1995 20:41:21 -0400 From: steve2@genesis.tiac.net (Steve Gerakines) To: hackers@FreeBSD.org Subject: Re: Minutes of the Thursday, April 13th core team meeting in Berkeley. Message-ID: <199504210041.UAA01973@genesis.tiac.net>
next in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504210041.UAA01973>