On Qui, 2016-12-08 at 09:17 -0500, 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.
> 
> 
> 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
>      release.
> 
>   5. And same for F26.1 final
> 
>   6. And sometime in October/November, release that (but without big
>      press push).
> 
>   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 like the idea of option 2 or any idea that may give us more stable
releases. And I think we should work on this idea since I am not alone
:) 

I wrote something near to that, years ago,  F26.1 final be a new base
i.e. all updates go to the base repo  when F26.1 release . 
I'm thinking also in post-release idea , so maybe, the plan could be
something like : 
F26 GA , one month later F24 EOL and F26.1 at same time and just
another month later F27 branch. This idea avoid duplication of QA work
in stable and devel branch at same time and QA just begin to work on
devel branch one (or two) month(s) later.

Best regards.
> 
> Some of this idea, by the way, is reminiscent of Spot's suggestions
> at
> FUDCon Lawrence in 2013. This is not completely coincidence - I
> always
> liked those ideas!
> 
> 
-- 
Sérgio M. B.

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to