[openstack-dev] [all][tc] Stabilization cycles: Elaborating on the idea to move it forward
flavio at redhat.com
Thu Jan 21 12:51:24 UTC 2016
On 21/01/16 11:55 +0100, Thierry Carrez wrote:
>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.
Precisely my point. If there's a way, from a governance perspective, to help
communicate and encourage folks to do this, I wan't to take it. It was mentioned
that some teams didn't know this was possible others that felt it was going to
be really hard w/o any support from the governance team, hence this email and
>>For example, we would
>>have to formalize how projects announce they want to have a
>>(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
>I actually wouldn't mind if that feature strategy decision was part of
>the PTL election platform -- it sounds like that would trigger
I wouldn't mind it either. However, I'd like us to stop having such a hard
separation between current PTL's plans and future PTL's. As a community, I'd
like us to work harder on building new leaders and a better community. I'd like
current PTLs to find in the community who would like to run for the PTL role
(regardless of the current PTL planning re-election) and work with them towards
having a better long term plan for the project. We should really stop thinking
that our responsibilities as PTLs start when the cycle begins and end when our
term ends. At least, I don't believe that.
That is to say, I'd like these plans to be discussed with the community in
advance because I believe the project will benefit from proper communication.
If I run for PTL and win because I proposed a stabilization cycle, I might end
up with a good plan and no ppl due to their tasks being re-scheduled because
their management doesn't want them to spend so much time "just fixing bugs".
>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.
As I mentioned in a previous reply, I think projects could also have a
stabilization milestone rather than a full cycle.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the OpenStack-dev