On Tue, 30 Mar 2004, Sandy Pond wrote:
On Tue, 2004-03-30 at 08:39 -0500, Robert P. J. Day wrote:
> one final point. traditionally, the whole testing cycle
suggests that, as
> one gets closer and closer to the official release, beta releases are
> theoretically supposed to get more and more reliable. put another way,
> it's a bit unnerving to suddenly discover that something that worked just
> fine in test1 is broken in test2, *especially* something as critical and
> fundamental as installation.
Well I think the release announcement say it all. There are several new
things that weren't in FC2T1. And I don't want them to freeze the
release to soon. If they do they'll be getting even more static about
not updating packages.
without trying to beat this to death, there is one thing about this that
concerns me. it's already been pointed out that there will likely be no
respin, since there is a workaround -- just boot off of the first CD from
FC2-t1, and switch to the FC2-t2 CDs after that.
fair enough, but what this means is that people who do that are not really
testing FC2-t2, are they? technically, they're testing the first install
part of FC2-t1, followed by FC2-t2 after that. does this really
constitute a technically acceptable beta test, in the strict definition of
the word?
more to the point, if there is no respin, there will be *no* testing of
this part of the install process until FC2-t3, which seems to be leaving
it awfully late.
think about it -- for all of the other software that is found to have
bugs, a fixed version would most likely be dumped into rawhide, at which
point, testers can update, test and say, "ok, that fixed it."
but based on what i've read, this is not going to happen for the
installation code -- there will be no *official* testing of a fix until
FC2-t3. am in reading that correctly?
rday