On Fri, Nov 10, 2017 at 6:18 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > On Fri, Nov 10, 2017 at 05:27:25PM +0100, Jan Kurik wrote: >> [1] 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 > that: > > 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: > > https://fedoraproject.org/wiki/Releases/28/Schedule (FESCo approved) > https://fedoraproject.org/wiki/Releases/29/Schedule (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 > missed something. 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 where > 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 worked > 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. Jan > -- > Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> > Fedora Project Leader > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
