[openstack-dev] [all][tc] Stabilization cycles: Elaborating on the idea to move it forward

Thierry Carrez thierry at openstack.org
Thu Jan 21 10:55:06 UTC 2016

Flavio Percoco wrote:
> [...]
> So, the above sounds quite vague, still but that's the idea. This email
> is not a formal proposal but a starting point to move this conversation forward.
> Is this something other teams would be interested in? Is this something some
> teams would be entirely against? Why?
> From a governance perspective, projects are already empowered to do this and
> they don't (and won't) need to be granted permission to have stabilization
> cycles. However, the TC could work on formalizing this process so that teams
> have a reference to follow when they want to have one.

I think "stabilization cycles" will come in all shapes and form, so it's 
hard to standardize them (and provides little value). They will mean 
different things and happen at different times for every project, and 
that is fine.

As you said, projects can already decide to restrict feature development 
in a given cycle, so this is nothing new. We only need to communicate 
more aggressively that it is perfectly fine (and even encouraged) to 
define the amount of feature work that is acceptable for a project for a 
given cycle.

> For example, we would
> have to formalize how projects announce they want to have a
> stabilization cycle
> (I believe it should be done before the mid-term of the ongoing cycle).

While I understand the value of announcing this "cycle feature strategy" 
beforehand, this comes slightly at odds with our PTL rotation every 
cycle: one PTL would announce a more stable cycle and then the next one 
would have to execute on a choice that may not be his.

I actually wouldn't mind if that feature strategy decision was part of 
the PTL election platform -- it sounds like that would trigger 
interesting discussions.

> Thoughts? Feedback?

Just an additional thought. It is not entirely impossible that due to 
events organization we'll accidentally have a shorter cycle (say, 4 
months instead of 6) in the future here and there. I could totally see 
projects take advantage of such a short cycle to place a "stabilization 
cycle" or another limited-feature-addition period.


Thierry Carrez (ttx)

More information about the OpenStack-dev mailing list