While I'm waiting for an RC5 test install to complete... :) At yesterday's FESCo meeting, while discussing the Fedora 22 schedule, Stephen Gallagher suggested the idea of moving to a release schedule modeled after Intel's "tick-tock" model for CPUs, where they alternate between new architectures and new manufacturing process. For us, that would mean alternating between concentrating on release features and on release engineering and QA process and tooling. During the "tick", we'd focus on new features and minimize unrelated rel-eng change. During the "tock", we'd focus on the tools, and minimize change that might affect that. This is meant to * allow us to continue improving release and testing infrastructure without needing another long cycle * prevent compounded delays caused by intersection of feature needs and releng changes * by putting the "tock" release, with a focus on tooling, in the fall, we reduce the risk of external bugs in upstream projects pushing us back into the December holiday period again * set user expectations and marketing differently for each release; more cautious users might skip the new-feature-focused "tick" release. There has also been some previous talk of a "polish" release, where we focus exclusively on bug-fixes big and small, and delay big features, including holding GNOME and other showcase software to the same version. That's a possibility still, but it would require significant collaborator consensus to really make work, and I don't think we have that. (We still have "first" as a foundation, after all.) So the tock release _wouldn't_ be that. New features and even big updates would be accepted, as long as they don't put infrastructure improvement plans at risk either through overlapping code changes (which should be somewhat rare) or through resource conflicts (maybe less rare). And during the tock, we'd be much, much more strict about activating feature contingency plans at alpha rather than later, so that post-alpha feature changes don't require as many test and release candidates, consuming QA and releng time. What do you think? Would this help towards the goals listed above? Would it help _other_ things? What downsides would it bring? -- Matthew Miller mattdm@xxxxxxxxxx <http://mattdm.org/> Fedora Project Leader mattdm@xxxxxxxxxxxxxxxxx <http://fedoraproject.org/> -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
