Date: Wed, 18 Mar 1998 10:59:27 -0700 (MST) From: Wes Peters - Softweyr LLC <softweyr@xmission.com> To: mvh@netcom.com (Michael V. Harding) Cc: stable@FreeBSD.ORG Subject: Re: 'Code Freeze' Message-ID: <199803181759.KAA21709@xmission.xmission.com> In-Reply-To: <199803181311.FAA02549@netcom1.netcom.com> from "Michael V. Harding" at Mar 18, 98 05:11:14 am
next in thread | previous in thread | raw e-mail | index | archive | help
Michael V. Harding opined:
> I'll have to agree with the below - my experience has been that the
> CDs are the LEAST stable releases. Also, look at this slice code
> change - it was introduced either after the code freeze, or right
> before it. The CDs should have a longer test period, maybe a month of
> real code freeze. I realize that this makes things harder for
> developers, but the stability of the CD release is very important -
> this is how most people get introduced to FreeBSD.
>
> <snip>
> Absolutely the worst thing any developer can do is to rush code into a
> release at the last minute. The current practice of announcing release code
> freezes encourages precisely that bad behavior. The result to a long time CD
> subscriber like myself is that I have _never_ received a FreeBSD CD that is
> useful to me by itself. There always seems to be some ugly bug discovered
> within a month of the CD going to press that requires me to use the CD only
> as a bootstrap method to get to current STABLE -- which is always reasonably
> stable, unless Jordan has announced a code freeze recently.
> <snip>
I unfortunately have to agree, the last several CD releases have been
unstable enough that even I had to update to -stable a month or so
after the release, and I am relatively undemanding of my FreeBSD
systems. (They are primarily used as cross-development systems for my
embedded work).
Perhaps we need to introduce a more defined release structure, where
the release is announced with a 4 to 6 week 'alpha' phase, where final
features are introduced, a 4 to 6 week 'beta' phase, where only bug
fixes and removal of unstable alpha features is performed, and then a 2
to 4 week 'Early Availability' or 'FCS' phase is closely monitored,
prior to pressing the CDs.
I offer this not as a criticism of the excellent work already done by
the FreeBSD team, but as an observation from an experienced engineer
who has fathered a couple of commercial products through the growth
that FreeBSD is now experiencing. As the product and the customer base
grows, and the variety of installed systems grows, the release
processes must grow to keep up. Unfortunately, this makes them take
longer as well, but that is inevitable.
Another suggestion I have is to *not* do the release preparation on the
-stable branch. I know this adds yet another branch to an already
large development tree, but history has shown that once we start the
integrate-athon that happens before every release, stability wanes for
a time. To me, the preparation for a release has *nothing* to do with
maintaining a stable tree, and therefore shouldn't break people who
want to cvsup -stable to keep their systems up to date.
Many thanks again to everyone who contributes to FreeBSD, and most
especially the core team. This is a marvelous work you have created.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.xmission.com/~softweyr softweyr@xmission.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803181759.KAA21709>