"Tick-tock" release cadence?

Bruno Wolff III bruno at wolff.to
Thu Dec 4 17:02:28 UTC 2014

On Thu, Dec 04, 2014 at 09:39:35 -0500,
  Matthew Miller <mattdm at mattdm.org> wrote:
>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.

Presumably we wouldn't need to do this even up. We want say 2 to 1 or 
3 to 1.

>This is meant to
> * allow us to continue improving release and testing infrastructure
>   without needing another long cycle

I am not sure that this will really work. The issue with testing was the 
testing team didn't have enough time to test and to develop. That is 
still going to be an issue for release emphasizing tooling. I think, for 
this one, recruiting more help is a better answer.

> * prevent compounded delays caused by intersection of feature needs
>   and releng changes

There was a bit of that this time. But this was a really big change. Are 
you thinking we will have this scale of change for releng on a regular 

>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.)

I think delaying big features for distro wide polish goes too much 
against our First objective. Having people work on bug fixes and 
other polishing that doesn't block unrelated development is always going 
to be welcome.

>What do you think? Would this help towards the goals listed above?
>Would it help _other_ things? What downsides would it bring?

I don't think we should force this. I think when developing goals for 
releases we look for conflicts and defer some things where there is 
a potential conflict. We'd want to make sure that desired goals eventually 
get done and not keep deferring the same goal repeatedly (because of 

More information about the devel mailing list