Matthew Miller wrote:
Option 1: Big batched update
1. Release F26 according to schedule
2. At the beginning of October, stop pushing non-security updates
from updates-testing to updates
3. Bigger updates (desktop environment refreshes, etc.) allowed into
updates-testing at this time.
4. Mid-October, freeze exceptions for getting into updates-testing
5. Test all of that together in Some Handwavy Way for serious
problems and regressions.
6. Once all good, push from updates-testing to updates at end of
October or beginning of November.
This is highly impractical. We really want bug fixes to go out! (IMHO, this
is a showstopper in that proposal.) The branching option is more realistic.
However, I also do not see why we cannot just do such big updates through
the regular update process rather than in a big .1 drop. The KDE SIG has
experience with pushing big grouped updates that look a lot like a .1
release for Plasma users. They go through the regular update process just
fine. Grouping them together with updates to GNOME, LibreOffice etc. in one
batch is not necessary and would only add unnecessary delays.
I think pushing all updates in a big drop will actually make them LESS
tested than if they just trickle through one at a time.