Open Stack

This is something I'd really like to see happen. It's an idea we've been
tossing around for the Keystone project, or at least a release with minimal
features, maybe 1 or 2. More comments in line

Steve Martinelli
Keystone PTL

Flavio Percoco <flavio at redhat.com> wrote on 2016/01/20 08:23:02 AM:

> From: Flavio Percoco <flavio at redhat.com>
> To: openstack-dev at lists.openstack.org
> Date: 2016/01/20 01:01 PM
> Subject: [openstack-dev] [all][tc] Stabilization cycles: Elaborating
> on the idea to move it forward
>
> Greetings,
>
> At the Tokyo summit, we discussed OpenStack's development themes in a
> cross-project session. In this session a group of folks started
> discussing what
> topics the overall community could focus on as a shared effort. One of
the
> things that was raised during this session is the need of having cycles
to
> stabilize projects. This was brought up by Robert Collins again in
ameeting[0]
> the TC had right after the summit and no much has been done ever since.
>
> Now, "stabilization Cycles" are easy to dream about but really hard to do
and
> enforce. Nonetheless, they are still worth a try or, at the very least, a
> thought. I'll try to go through some of the issues and benefits a
> stabilization
> cycle could bring but bear in mind that the lists below are not
exhaustive. In
> fact, I'd love for other folks to chime in and help building a case
> in favor or
> against this.
>
> Negative(?) effects
> ===================
>
> - Project won't get new features for a period of time Economic impact on
>   developers(?)
> - It was mentioned that some folks receive bonuses for landed features

This is a thing?! Really? I'm very surprised about this one, features
should only be included in a project if they make sense strategically for
the project. PTLs should -2 the spec if they feel it doesn't align with the
project's direction. No?

> - Economic impact on companies/market because no new features were added
(?)

I'd argue this could be spun into a positive. We get enough grief about
difficulty and complexity of OpenStack, by focusing on paying down
technical debt, we likely going to addressing some of the issues that make
things complex. We are actually listening to feedback instead of plowing
ahead with features no one uses cause they're still on Juno.


> - (?)
>
> Positive effects
> ================
>
> - Focus on bug fixing
> - Reduce review backlog
> - Refactor *existing* code/features with cleanups
> - Focus on multi-cycle features (if any) and complete those
> - (?)
>
> A stabilization cycle, as it was also discussed in the aforementioned
> meeting[0], doesn't need to be all or nothing. For instance, it should be
> perfectly fine for a project to say that a project would dedicate 50% of
the
> cycle to stabilization and the rest to complete some pending
> features. Moreover,
> each project is free to choose when/if a stabilization cycle would be
good for
> it or not.
>
> For example, the Glance team is currently working on refactoring the
image
> import workflow. This is a long term effort that will require at
> least 2 cycles
> to be completed. Furthermore, it's very likely these changes will
> introduce bugs
> and that will require further work. If the Glance team would decide
> (this is not
> an actual proposal... yet :) to use Newton as a stabilization cycle, the
team
> would be able to focus all its forces on fixing those bugs, completing
the
> feature and tackling other, long-term, pending issues. In the case of
Glance,
> this would impact *only glance* and not other projects under the Glance
team
> umbrella like glanceclient and glance_store. In fact, this would be a
perfect
> time for the glance team to dedicate time to improving glanceclient
> and catch up
> with the server side latest changes.
>
> 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. 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).
>
> Thoughts? Feedback?
> Flavio
>
>
> [0] http://eavesdrop.openstack.org/meetings/tc/2015/tc.
> 2015-11-03-20.07.log.html (20:47:02)
>
> --
> @flaper87
> Flavio Percoco
> [attachment "signature.asc" deleted by Steve Martinelli/Toronto/IBM]
>
__________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160120/4472f7d3/attachment.html>