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.
Regards,
--
Thierry Carrez (ttx)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
