On jueves, 8 de diciembre de 2016 9:17:14 AM CST Matthew Miller wrote:
Trying to make this idea a little more concrete. Here's two
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
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.
Option 2: Branching!
1. Release F26 according to schedule.
2. July/August: branch F26.1 from F26 (not rawhide)
3. Updates to F26 also go into F26.1 (magic happens here?)
4. No Alpha, but do "Beta" freeze and validation as normal for
5. And same for F26.1 final
6. And sometime in October/November, release that (but without big
7. GNOME Software presents F26.1 as upgrade option
8. F26 continues in parallel through December
9. In January, update added to F26 which activates the F26.1 repo.
10. And also in January updates stop going to F26.
I have been talking with adamw about dropping alpha releases entirely. I was
planning to outline all of it at DevConf but the talk was rejected so I will
have to find another way to lay out the plans I have to change many things.
I would like to see us stop pushing non security updates to updates from
updates-testing entirely and do it in monthly batches instead. we would push
daily security fixes and updates-testing. However this would make atomic host
2 week releases much less useful, as there would be no updates except for once