RPM version goes backward in Rawhide

[Adam Williamson]

On Fri, 2011-08-05 at 05:10 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > You don't make any attempt to engage with the reason for it: to ensure
> > that updates get sufficient testing.
> 
> I kinda did, with the next paragraph (which you are quick to dismiss as off 
> topic). :-)
> 
> People will test the stuff when it's marked stable, and that way they 
> actually test what will be in the release (or the Alpha or Beta).

That's ass backwards, though. We need the testing _to determine if the
things should be in the release_. Really, I think if you look at the
quality of the releases that have happened since this policy was
changed, it's pretty clear that it helps. It makes pulling together the
pre-releases a lot less chaotic.

> > changed, you should at least engage with why it is the way it is, and
> > explain why you think the benefits of not enabling updates-testing by
> > default in Branched releases (which, to me, seem marginal: it saves
> > people who run pre-releases and then update to final a bit of trouble)
> > outweigh the drawbacks (which, in the shape of reduced feedback on
> > testing updates for Branched releases, could be significant).
> 
> 1. I don't consider the upgrade path issue "marginal" at all. If people 
> install our prereleases, they expect to be able to upgrade to the final 
> release seamlessly. 

We're very clear about what you get to expect with pre-releases, and
being able to upgrade to the final release seamlessly certainly isn't
one of those things.

> At each release, we get bug reports about "broken 
> upgrade paths" from Beta to Final which are actually just a result of 
> updates-testing getting magically disabled (and keeping it enabled wouldn't 
> be that great a solution either).

Sure. I don't see that as a huge issue. We explain why it happens and
provide the solution - distro-sync - and people are generally fine with
that. I haven't seen anyone who thought it was a terrible idea yet.

> 2. Updates-testing tends to contain very broken stuff, for which the 
> maintainer knows it needs more testing before being proven usable (or not). 

One, that's certainly not how updates-testing is supposed to work, and
two, I dispute that it's the case in practice. Could you point to an
example?

> Enabling it by default makes Branched more unstable than it could be (and in 
> some cases, even more unstable than Rawhide, as the EVR monotonicity issue 
> which is the subject of this thread shows).

Erm, the update in this thread happened in Rawhide; F16 was not branched
at the time. If F16 had been branched, the update would never have made
it out of updates-testing, hence much less of a problem. Making it less
likely that we'll have to do reversions / epoch bumps is one of the
*strengths* of the updates-testing system.

> 3. People testing with updates-testing enabled aren't testing what will 
> actually end up in the releases (Alpha, Beta, Final), which use only 
> packages marked stable.

Sure. But their testing enables us to make good decisions about what
*should* go into the release. I don't see where this is a problem.

> 4. Updates-testing being enabled by default means that people installing an 
> Alpha or Beta immediately get fed tons of 0-day (actually negative-day) 
> updates, because the Alpha or Beta does not include those testing updates by 
> design. It makes it look quite pointless to work on stabilizing the Beta 
> when people who installed the Alpha and ran "yum update" are already using 
> newer packages than those the Beta will ship before the Beta is even being 
> prepared.

It's not at all pointless, because the point of the Alpha / Beta images
is to provide a known-good base. If the Alpha / Beta are broken, you're
pretty screwed. If an update is broken, just re-install from the
known-good base and skip the update.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net