As I said in the meeting let's just deprecate it. Upgrade methods as follows:
1) YUM 2) DVD It's just an extra thing to worry about and I know I'm gunna get flamed, however I say we just do away with it or have it perform very minimal tasks so yum can do the upgrade by itself. I remember upgrading from 11->12->13->14 by simply pointing to a new yum repo. So maybe instead of deprecating preupgrade, just gimp it to what it needs to do so yum can do the rest. I really believe that Yum can do this and preupgrade can be deprecated or perform less work while yum can play a bigger role (as it should). Feel free to flame/insult/tell me I'm wrong for whatever reason, just throwing it out there and trying to make life easier. Thanks, Dan -----Original Message----- From: test-boun...@lists.fedoraproject.org [mailto:test-boun...@lists.fedoraproject.org] On Behalf Of Adam Williamson Sent: Monday, April 09, 2012 7:14 PM To: test@lists.fedoraproject.org Subject: Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases 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@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
