"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
basis?
>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
conflicts).
More information about the devel
mailing list