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.
I want fast moving improvements and fixes. Packages are tested by the
developer before going to rawhide for testing. If this moves to fast
for you then get off the rawhide channel but don't slow everyone down.
Doing as you suggest would severely cripple the testing/bug reporting/
fixing process by adding more internal loops.