Open Stack

On 20/01/16 12:53, Flavio Percoco wrote:
> 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 a
> meeting[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

o.O

Is this real life???

> - Economic impact on companies/market because no new features were added
> (?)
> - (?)
>
> Positive effects
> ================
>
> - Focus on bug fixing

Or maybe just a focus on anything but upstream OpenStack work

> - Reduce review backlog

Or increase the review backlog.

Or leave it about the same. It'll definitely be one of those.

> - 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.

I guess not being all-or-nothing is a good thing, but in that case what 
does this even mean in practice? If there's a review up for a feature 
what would you do differently under this policy? Merge half of it? Flip 
a coin and only review if it comes up heads?

> 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?

I actually hate this idea really quite a lot, largely for the same 
reasons that Julien and Dan have already articulated. Honestly, it 
sounds like the kind of thing you come up with when you've given up.

Instead a project could develop a long-term architecture plan that makes 
the features on its roadmap easier to implement in a robust way. Or 
introduce new features that simplify the code base and reduce the 
prevalence of existing bugs. Or demand working, tested, incremental 
changes instead of accepting unreviewable 5k line feature patches. Or 
invest in improving testing. Or break the project up into smaller units 
with clear API boundaries and give them specialist review teams. Or get 
a bunch of specialist exploratory testers to find bugs instead of 
waiting for them to affect developers somehow. Or... YMMV for any given 
idea on any given project, but the point is that saying "ok, no more 
features" is what you do as a last resort when you have literally zero 
ideas.

I guess it bugs me because I think it's an instance of a larger class of 
problem, which is characterised by the notion that one's future, better 
informed self will somehow make worse decisions than one's current self. 
i.e. you assume that you're getting stupider over time, so you decide to 
ignore the merits of any individual decision and substitute a default 
answer ("no") that you've formulated a priori. In a way it's the 
opposite of engineering.

</rant>

>  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).

So all that said, if individual projects want to experiment with this 
then any possible damage is fairly localised and if they write up their 
experience then we'll all learn something which has to be good. However 
I think including it as part of the standard operating procedure and 
encouraging mass adoption before any project has tried it is highly 
premature.

Finally, I don't think that *any* project is currently under the 
impression that that TC has mandated that they merge every feature 
proposed, so I'm not quite sure why this discussion is needed.

> Thoughts? Feedback?

I think the discussion about how to encourage a change like this across 
a large swathe of OpenStack should happen at the "hey, we just tried 
this, here's what worked, here's what didn't" stage, not at the "hey, I 
just had this great idea" stage.

cheers,
Zane.