Testing test releases: do [ESC d]not update

Phil Schaffner P.R.Schaffner at IEEE.org
Fri Feb 27 17:05:34 UTC 2004


On Fri, 2004-02-27 at 10:15 -0500, Sandy Pond wrote:

> On Fri, 2004-02-27 at 09:31 -0500, Phil Schaffner wrote:
> > however, the rate of package updates via rawhide has been rather
> > overwhelming and makes me wonder at the value and efficiency of testing
> > such a fast-moving target.  I realize it would be more work, but perhaps
> > an approach with multiple stability levels like FC1 (updates, testing)
> > or ATrpms (at-stable, at-good, at-testing, at-bleeding) repository
> > hierarchy (probably with fewer levels) would provide an opportunity for
> > better in-depth testing of some of the more stable packages in a
> > somewhat more stable environment, while allowing the real bleeding edge
> > fans to drink from the rawhide fire-hose.
> > 
> 
> I agree with Mike and Jef;
> 
> Jef Spaleta wrote:
>   In my opinion, the biggest bottleneck is utilization of
>   developer time...developer time is the scarce resource. Building
>   a testing process thats most convenient for the testers but puts
>   an undue burden on the developers isn't a process based on the
>   realities of the resource economics involved.
> 
> Mike A. Harris wrote:
>   *EXACTLY!*  Someone *GETS* it.

Points taken.  Composed my message late last night before the above were
written but an ISP outage kept it from going out until this morning.

> I want fast moving improvements and fixes.  Packages are tested by the
> developer before going to rawhide for testing.

But many eyes are the reason for testing in the first place.

> If this moves to fast
> for you then get off the rawhide channel but don't slow everyone down.

I'll hang in there as best I (and my cable-modem - currently downloading
latest updates) can, thanks. Please don't wait. :^)

> Doing as you suggest would severely cripple the testing/bug reporting/
> fixing process by adding more internal loops.

Was trying to propose an approach that might increase efficiency of the
end-to-end testing process without undue burden to developers, but the
above arguments are convincing. Let's keep rolling, rolling...

Phil






More information about the test mailing list