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

[Axel Thimm]

On Fri, Feb 27, 2004 at 10:57:04PM -0500, Sandy Pond wrote:
> On Sat, 2004-02-28 at 01:56 +0100, Axel Thimm wrote:
> > On Fri, Feb 27, 2004 at 10:15:34AM -0500, Sandy Pond wrote:
> > > 
> > > 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.
> 
> I do very much appreciate your contributions as well as the other third
> party repos.  But Redhat already has three levels in FC1.

I see base packages as "shipped" on the release day and updates as the
same stability class. updates/testing is the new stability class.

> The FC2 test1 snapshot is somewhat stable, as probably the FC2 test2
> snapshot will be.  Now some people want to add more development
> loops to the development channel.

rawhide/development is just fine as it is, and test releases should
not have updates. While currently there are statements that say
updates for test releases are found in rawhide/development, this is a
rephrasing of "No updates for test releases, but you can jump onto
rawhide, while it is still timely close to the test release".

IMO bug reports and discussion about non-updated test releases belong
to "test" and such of "updated test releases, aka rawhide" belong to
"devel" entities (which is what I wanted to say at the beginning of
this thread and was partly misinterpreted as a request for update
channels for test releases).

It's perfectly alright for the development model. Test releases are
rawhide snapshots which have been stabilized more than the usual
rawhide to allow for distribution and testing of a special development
environment. That's all. There are benefits for the developing from
both bug reports from non-updated test releases, as well as from
rawhide trackers. If the ratio becomes bad to either direction, I
guess there will be actions to make the other side of the scale more
attractive.

Another question raised is suitability of rawhide for wider testing,
e.g. a better stability handling. One would have to think about
offering stability segmentations in rawhide (something like
rawhide-testing vs rawhide-experimental, new/updated packages entering
the latter and being moved to the former after some given time). No
waste of resources other than the initial setup, and could offer
benefits, as more users would be willing to track the time-delayed and
somewhat tested rawhide-testing repo.

Currently I believe there isn't really a demand/need from the
developers' POV for the above solution (and their POV is the important
one for beta/devel stuff), but maybe in the future this may change and
be reviewed if increasing the testing userbase becomes an issue.

> I say let's leave it alone and reserve the development channel as a
> streamline for quickly pushing new packages, finding bugs and
> getting them fixed as quick as possible.  Frankly, I'm finding
> rawhide much stabler than in the past when I've played with it.
> 
> I think if you need a stable machine use FC1 (Jeez ... I got one machine
> that still has RH8 on it that I got to get to) ... if you need a
> testing/development machine then use FC2.  

Did we disagree? ;)
-- 
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/20040301/47c114d1/attachment.sig>