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