On 11/27/18 7:54 AM, Ben Cotton wrote:
On Tue, Nov 27, 2018 at 8:21 AM Justin Forbes <jmforbes@xxxxxxxxxxx> wrote:
Long cycles have been done before, and will be done again, it has been
4 or 5 years since the last one. I think skipping to a yearly cadence
for every release isn't such a great idea. There are benefits to the
cadence we have, but I do think perhaps a plan to regularly do this
might be a good thing.
Agreed. Doing a long cycle is a tradeoff. In general, the six month
cycle works for what we're trying to do. But having the occasional
long cycle gives us some space to work on bigger projects or things
that can't be done while we're also trying to get a release out the
door. With unlimited funding and people, we wouldn't have to make this
tradeoff, but we do have limits.
I'm sympathetic to the argument that we should do it as needed, but my
preference is to schedule it. This allows our community to plan ahead,
both for the work to be done during the long cycle and also for things
that should get done before and after. Predictability is helpful.
If we do say, for example, every 8th release will be a long cycle
there's nothing that would prevent us from doing an unscheduled long
cycle if we have to. But it would have to be a very compelling reason
knowing that we'd have another long release coming up.
The other way to slice it is having some parts of the distribution be
on a longer cycle and others on a shorter cycle. If there is a 1 year
gap between F30 and F31, perhaps the rules for what can be updated in
F30 could be revised to maintain the value people get from the 6 month
release cycle.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
