On Thursday, December 8, 2016 9:17:14 AM CET Matthew Miller wrote:
Trying to make this idea a little more concrete. Here's two
suggestions
for how it might work. These are strawman ideas -- please provide
alternates, poke holes, etc. And particularly from a QA and rel-eng
point of view. Both of these are not taking modularity into account in
any way; it's "how we could do this with our current distro-building
process".
Option 1: Big batched update
1. Release F26 according to schedule
https://fedoraproject.org/wiki/Releases/26/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
even.
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.
[..]
I'm lost. I'm against prolonging delays before pushes from
updates-testing to updates if there's given karma, even for non-security
stuff. If that's not enough, we should shape the karma-process.
Option 2: Branching!
[..]
Sounds really complicated to me. What's the purpose?
--
I probably lost the context ... what real-world problems are trying to fix?
Everything which comes to my mind should be solved by better tooling for
updates-testing testers.
Have you considered the recent "bodhi for rawhide" proposal, too?
Pavel