On Thu, 2014-12-04 at 06:16 +0100, Ralf Corsepius wrote: > Untrue. All you need to do is to apply the "after release" update policy. > I.e.: push updates to "updates" on both Fedora(N) and Fedora(N+1). When > you need to cut a snapshot, move Fedora(N+1) updates into the main > repository. Hum. It might be possible to use the branched updates during freezes in that way, yeah. Have to see what releng thinks. > > 2. Implement a perfect and strictly-enforced upgradepath test and > > abandon milestone freezes > > > > The consequence of this would be be we'd probably never manage to get > > the damn milestone releases done because people would keep pushing > > changes that break them. > > > > Neither of those seems likes an improvement on the current situation to > > me. > Well, right now, you can't test upgrading and are likely to be broken > upgrade paths (as Fedora had always done). You can test fine; just test with updates-testing. Testing upgrades as a 'release time' test is fundamentally kind of artificial, especially with our current fedup design, because it's fundamentally not a 'release time' operation. The only thing it really makes sense to test as a 'release validation' test is the upgrade.img in the frozen tree, because that's the only element that's tied to release. Otherwise, upgrade is always a moving target. We can't test what the upgrade experience will be in a month, or a week, because it uses the 'updates' repository in most configurations. Just for the purpose of testing upgrade.img, you can simply enable updates-testing if it turns out you have a situation like this and you need a package from u-t to make the upgrade package set viable. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
