On Fri, Nov 10, 2017 at 6:18 PM, Matthew Miller
On Fri, Nov 10, 2017 at 05:27:25PM +0100, Jan Kurik wrote:
>  https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
This looks generally good to me. The one change I would make is to
add to "Tue: Primary date from which rest of schedule derives". Make
Tue: Primary date from which rest of schedule derives
This date is either the Tuesday before May 1st or October 31st.
Upcoming potential target dates are: 2018-04-24, 2018-10-30,
2019-04-30, and 2019-10-29.
I added the "This date is either the Tuesday before May 1st or October
31st." sentence which makes sense to me. However I would not be happy
to add exact dates in a policy. A policy should be a general document.
Having exact dates can make it obsolete in case of any action we might
take in a future with a schedule for a particular release.
Can you draw up how exactly any changes would affect:
(still a draft)
I think offhand that they're basically the same (and that this change
basically brings the policy in line with the praxis), but I may have
There should be no major changes in the 28 and 29 schedules. Except
naming of some milestones (replacement of the Rain date) the only
milestone which is going to change is "String freeze".
On a bigger note: Do we really want to have a window after branch
Bodhi isn't active? Might it be better to put that as part of the
Branch step? I don't think we want a longer freeze period (especially
during beta) but we
I am adding Mohan (release engineering) on CC to answer this question.
And, on a even bigger note, the F27 July-to-October experiment
reasonably well (with the large remainer of the still-outstanding
Modular Server) but I don't think we want to do that again. I'd like to
suggest that if the April/May release slips into July, or the
October/November release slips into January, we *automatically* skip
the next target date for a _longer_ cycle to bring us back to schedule
rather than a short one.
In my opinion, having a shorter cycle is better option than completely
skip one release. A shorter cycle puts us under stress, but we still
have things under control. Skipping a release might have many
consequences we might not even think of, like issues with branching
etc. I would be quite conservative here.
Fedora Project Leader
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic