Open Stack

Robert Collins wrote:
> We had a process track session about bringing in upstream continuous
> deployment for openstack.
> https://etherpad.openstack.org/HavanaContinuousDeployment
> [...]

Most of the outcomes of this session seem to be well-accepted, but a
number of them are a bit controversial, as can be seen from the rest of
this thread.

>  * No more big landings [except the purely mechanical]. Set a hard
> limit - maybe 500 lines of diff. Big landings are more risky per line
> of diff than small ones due to reviewer cognitive overhead - reviewers
> get non-linearly less effective the larger the review.

Like Russell said, this is enforced at review level for certain
projects. Do you think it should be made a general rule for all projects ?

>  * No more cramming: when a freeze is happening, anything that is
> 'land this for the release' has to be pushed back on -really hard-. If
> its not ready, it's not ready.

I think we are slowly getting better at this. There are two aspects to
avoiding a peak in feature landing: the guts to say "wait next release"
to not-so-great stuff as we near feature freeze (which you mention) and
the communication of the value to spread feature landing across the ~5
months of our release cycle feature window.

To enforce the latter, we need to have all features tracked as
blueprints and targeted to a given development milestone, which would
let us check in advance that havana-3 is not more busy than havana-2,
and reject stuff preemptively if it is. In practice, there is still a
lot of untracked work, and too many features targeted to the last
milestone. I'd welcome more editorial control on the featureset, but I'm
not sure we are collectively ready to reject good stuff just because too
much other stuff was previously lined up. So maybe communicating around
the value of spreading the landings is the best we can do at the moment.

>  * Land features disabled by default. Such disabled features are
> experimental and we don't need to be so careful - we can in fact
> remove them entirely if they turn out to be bad idea - when they
> become supported (individual teams can define this we think) they
> can't be broken again though: they are now part of the product.

That's the most controversial part. You make a good case of how this is
easier than the "collection of relatively-small patchsets" approach, and
potentially better for CD (I'm still not totally convinced that
switching a full feature ON at some point rather than landing
incremental patchsets is less disruptive for CD, but you know that stuff
better than I do).

Personally my experience of OpenStack project management makes me fear
that your proposal ignores the reality of our unmanaged development
workforce: there is no way we can be sure that a feature will actually
be completed. So you might end up having disabled code in releases... or
force the removal of the already-landed parts at the very last moment,
which is disruptive to release quality and also sounds more disruptive
to CD than what you are trying to protect against.

One intermediary approach could be that this kind of disabled features
need to be enabled by ~havana-2, to give us plenty of time to remove
them before havana-3 if they are not complete... Additional benefits
being that those "large features" land in the middle of the cycle rather
than at the very end.

> How do we get all this into place : I can update wiki pages etc, but
> is any more agreement needed? Should the TC eyeball it?

This thread shows that more discussion is definitely needed. Depending
on the actual reach of the finally-accepted changes, it may require a TC
discussion / blessing... but at this point it seems to be each project
territory, so convincing the PTL and the core teams of each project to
amend how they do feature acceptance and reviews is probably the best
way forward.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack