Hey, folks. So, it occurred to me while testing the multiple preupgrade bugs we've hit this cycle that - as I understand the process - there's actually no reason we need to hold Alpha and Beta composes for preupgrade bugs. This is how preupgrade works: it pulls https://mirrors.fedoraproject.org/releases.txt , and that's the list of releases it shows you at the first step. It uses the locations defined in that file to retrieve everything - both the packages it downloads and feeds to anaconda, and the actual anaconda that it uses. releases.txt points out to our mirrors.fedoraproject.org mirror lists, and I'm reliably informed (by nirik) that, for pre-releases, the mirror list points to the development tree - that is, http://fedora.mirror.iweb.ca/development/17/x86_64/os/ , for example. It does not point to the frozen tree of the last 'official' pre-release (of which there is also one on the mirrors - it's at http://fedora.mirror.iweb.ca/releases/test/17-Alpha/ ). Since preupgrade for development releases uses the development tree, this means there's actually no relationship between preupgrade and the Alpha / Beta releases. If you run preupgrade from F16 to F17 right now, it doesn't use the anaconda from Alpha. It doesn't necessarily use whatever anaconda is in the latest Beta RC. What it uses is whatever anaconda was last pushed 'stable' via bodhi. Since we can push a new anaconda stable whenever we want, there's no reason I can see to hold Alpha or Beta composes for preupgrade issues. Putting the anaconda that 'fixes' a preupgrade problem into an Alpha or Beta release doesn't really achieve anything in and of itself. All we have to do is make sure the working anaconda is pushed 'stable' via Bodhi as quickly as possible, whenever the Alpha or Beta release point is. The situation for final releases is a bit different. For final releases, mirrorlist points to the 'frozen' release tree - for e.g. http://fedora.mirror.iweb.ca/releases/16/Fedora/x86_64/os/ . This tree is frozen in time at the state when the release went final. If we push an anaconda update stable for a final release, preupgrade to that final release does *not* use the new anaconda. So if right now we push an update to Fedora 16's anaconda stable, you won't get that anaconda when preupgrading from F15 to F16; you get the one from F16 release time. So for final release, we *do* need to make sure the anaconda in the frozen release package set is working for preupgrade. So, I'm proposing one of two options: 1) Simply bump preupgrade to the Final release criteria 2) Keep preupgrade in the Beta criteria, but treat all preupgrade issues - even those that are in the anaconda package - the way we currently treat blocker issues in livecd-tools or the preupgrade package itself: consider them as not blocking image compose. Rather, we require the maintainer to push out an update before the release date. We could put issues in anaconda that only affect preupgrade into the same category. We had a preliminary discussion about this at today's meeting, and agreed I'd make a formal proposal to the list - this is that proposal. Any concerns, questions, improvement suggestions or corrections are greatly welcomed! Please chip in your thoughts, and votes for 1), 2) or neither of the above. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
