[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

Robert P. J. Day (rpjday 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]