Testing test releases: do not update

[Ernest L. Williams Jr.]

On Thu, 2004-02-26 at 17:16, Mike A. Harris wrote:
> On Tue, 24 Feb 2004, Robert P. J. Day wrote:
> 
> >> I think that Robert Day's initial point is correct. If there is no
> >> stable baseline then testers are constantly finding superficial bugs;
> >> deep bugs that take hours of testing will never get reached. Alan Cox is
> >> also right when he states that a tester should check against the current
> >> state of rawhide before he reports a bug.
> >
> >the more i read posted on this, the more i'm coming to sort of
> >understand the other positions so, yes, i'm starting to
> >understand the philosophy of, this early in the release process,
> >just drive all of the changes out there and see what breaks.
> 
> That's how it has been for 10 years.  I'm not sure why some
> people think the processes that have been used all this time are
> all of a sudden bad.  Perhaps people just do not understand the 
> procedures and what to expect.
That is true.
However, is there not a Fedora 2 Test-l updates tree?  IF there is then
Testers should use that, right??



> 
> 
> >but i guess it means that, unlike previous test releases from
> >red hat, these early test releases really are unusable as
> >*anything* but test platforms.
> 
> Ah, but in the past, the public only got to see beta release 4, 
> 5, and 6.  The first 2-3 betas that destroyed the universe, were 
> not public, and so you did not see the level of breakage that 
> occured in earlier betas.  Now things are even more open, and 
> people who elect to see the level of breakage in early betas, can 
> now do so.  Those who do not want to see high level of breakage, 
> should really sit out a few test releases and wait for the OS to 
> stabilize.  Or should only test low-risk packages individually, 
> and not make changes to their core OS that could break 
> everything.
> 
> >as i mentioned in a previous post, it used to be that ambitious
> >testers would just flat out install the test release, knowing
> >that it would have problems, but they'd be prepared to deal with
> >that, *knowing* that as bugs were reported and patches issued,
> >their systems would slowly get more and more stable, and their
> >lives would return to normal.  well, as normal as testers' lives
> >get.
> 
> In the past though, as indicated above, the initial betas weren't 
> public, and so you never got to see just how broken things can 
> get.  ;o)
> 
> 
> >but with this new fedora approach, that's just not true anymore,
> >at least for the first release or two.  if one is constantly
> >updating against rawhide, then you have to assume that, as some
> >things get fixed, others will get broken.  which makes it pretty
> >much impossible to use such a system for useful work, no?  not a
> >complaint, just an observation.  :-)
> 
> That's a fair observation, but you should be aware that this is
> absolutely no different than any previous OS release, other than
> the fact it is an open process now.  We _NEED_ wider testing than
> we can do internally alone in order to get things in a more
> stable state.  That either means we do private beta releases with
> a selected team of individuals who 100% accept the deal about the
> chances of having a totally broken system for the private betas, 
> or we make it open, and let people decide for themselves.  We 
> chose the latter.  One thing we can _NOT_ do, is guarantee the 
> stability of the OS, when it is in early development, which is 
> where things are today.
> 
> 
> >based on what i read, it's only toward the very end of the
> >entire testing cycle (FC2-test3) that feature freezes start to
> >kick in and we should see things returning to normal in
> >preparation for the official release.
-- 
Ernest L. Williams Jr. <ernesto at ornl.gov>