Stability classes (was: Testing test releases: do [ESC d]not update)

[Axel Thimm]

On Fri, Feb 27, 2004 at 10:15:34AM -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.
> 
> 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.

You mean tagging packages as stable or less stable? I haven't
experienced slowing down or waste of developer time with stability
classification, on the contrary. Users can tune their system to their
liking and I can push out packages faster. Much like the new testing
updates FC1 introduced.

(BTW the above stability classes are due to be consolidated to three:
production/testing/experimental and for deprecated packages: graveyard)
-- 
Axel.Thimm at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20040228/ebc53fbd/attachment.sig>