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.