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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
