> Very frequently in such cases the entire test matrix is not completely > retested. A lot of prior tests a carried over because they're known > (or strongly suspected) of not having been touched in any way by the > fix of one or two blocker bugs. > > If hundreds of packages get unfrozen and sync'd all bets are off. The > state of the release is now sufficiently non-determinstic that it > means all testing has to be started completely from scratch. So I > would say no, this isn't a good idea, just because the resources > aren't there to do this additional amount of testing. > > The goal isn't to have a release that's super current. It's to have a > release that's stable and works. I think that Chris described it very well. I'm quite skeptical that such a proposal would work in practice because of these reasons. It's quite demanding for us to just fix and test the outstanding blockers. Updating everything would mean: a) retesting everything from scratch, and of course our testing covers only a few selected areas, we rely on many people from community to report blockers when they find them -- that takes time, not just a few days of testing crunch b) potentially breaking anything, from boot to installer to desktop environment to apps Of course if things break immediately after first system update, our users are not much better off. But at least the install medium booted and installer worked. The broken updates can be fixed, they are not baked into the install medium. Maybe we could consider some middle approach, where things not in the critical path (not directly affecting the core system and installer) would not be affected by freeze. That shouldn't break much and would help many pre-release users and maintainers. It can still introduce new blockers, though, if those apps are e.g. on Live medium or are installed by Server by default (and then don't start). So we could ignore freeze just for packages not being on any install medium. But then I'm not sure how much that is helpful and it might be difficult to implement this in Bodhi. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
