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