"Tick-tock" release cadence?

Matthew Miller mattdm at mattdm.org
Thu Dec 4 14:39:35 UTC 2014


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 at mattdm.org             <http://mattdm.org/>
Fedora Project Leader  mattdm at fedoraproject.org  <http://fedoraproject.org/> 


More information about the devel mailing list