Testing test releases: do not update (was: yum.conf that works)

[Bill Nottingham]

Robert P. J. Day (rpjday at mindspring.com) said: 
> > I would think the reason to have a test release is to have a well
> > defined point in development time to test against. If you point your
> > package resolvers to development/rawhide, then that's what you will be
> > testing instead.

Yes. Oddly enough, that's what will become the release eventually.

> or red hat could
> make everyone's life easy (including their own) and give everyone a single
> channel (in yum.conf) against which they could do a simple "yum update".  
> the beauty of that is that 1) it's easy for testers to keep up to date,
> and 2) it guarantees that everyone who uses that channel is running the
> same updated system, so that there's some consistency in bug reports.  
> and what single channel would that be?

The development channel. As it is.

> as it stands, FC2-t1 was shipped with yum.conf pointing at rawhide.  and 
> what a bad idea that was.  as more than one person has pointed out, 
> rawhide represents the latest, greatest, bleeding edge, 
> not-even-guaranteed-to-work software.

It's also what will become the release.

> to fix identified and known bugs, that makes sense.  but what's the point 
> of updating against rawhide?  it would make far more sense to have just an 
> "update" repo for test releases, representing just those packages that 
> were found to be broken.  if, instead, you update against rawhide, it 
> would seem you've so contaminated your original system, can you even call 
> it FC2-t1 anymore?

No, you call it the FC development tree. There's even a bugzilla
bucket for it.

> and for those who think it's too much work for red hat to do it this way,
> i submit that it's exactly the opposite.  when there's a test release out 
> in the wild, red hat should be spending their time dealing with bug 
> reports that represent things that are just flat out *broken*.  not stuff 
> from rawhide, not RFEs, not wish lists.

Except, a great majority of the RFEs and wish lists aren't filed
until the first test release is up. Aside from that...

> and that means not 
> having to deal with rawhide.  there should be a *separate* update channel 
> purely for fixing broken things.

This is a broken implementation.

If you run stock FC2 Test1: you're running a tree that's a snapshot,
at a point in time, of what will be FC2.

If you then update to rawhide as of a certain date: you're running a
tree that's a snapshot, at a point in time, of what will be FC2.

If you have a separate test updates channel: you're running a tree
that is *not* a snapshot of what will be FC2, but a mix and match of
various packages. Many of which may not be fully up to date.

Bugs against the first two are inherently more useful than bugs
against the third.

Bill