Date: Wed, 19 Apr 1995 22:20:04 -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: <199504200220.WAA17794@genesis.tiac.net>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504200220.WAA17794>