[openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

Jeremy Stanley fungi at yuggoth.org
Fri May 5 13:19:34 UTC 2017

On 2017-05-04 20:09:35 -0400 (-0400), Zane Bitter wrote:
> On 04/05/17 10:14, Thierry Carrez wrote:
> >Maintaining stable branches has a cost. Keeping the infrastructure that
> >ensures that stable branches are actually working is a complex endeavor
> >that requires people to constantly pay attention. As time passed, we saw
> >the involvement of distro packagers become more limited. We therefore
> >limited the number of stable branches (and the length of time we
> >maintained them) to match the staffing of that team.
> I wonder if this is one that needs revisiting. There was certainly a time
> when closing a branch came with a strong sense of relief that you could stop
> nursing the gate. I personally haven't felt that way in a couple of years,
> thanks to a lot of *very* hard work done by the folks looking after the gate
> to systematically solve a lot of those recurring issues (e.g. by introducing
> upper constraints). We're still assuming that stable branches are expensive,
> but what if they aren't any more?
> Speaking as a downstream maintainer, it sucks that backports I'm still doing
> to, say, Liberty don't benefit anybody but Red Hat customers, because
> there's nowhere upstream that I can share them. I want everyone in the
> community to benefit. Even if I could only upload patches to Gerrit and not
> merge them, that would at least be something.
> (In a related bugbear, whyyyyy must we delete the branch at EOL? This is
> pure evil for consumers of the code. It breaks existing git checkouts and
> thousands of web links in bug reports, review comments, IRC logs...)

The points above are all interrelated. We close upstream development
of a branch at some point (by tagging and deleting it) to ensure
contributors _don't_ post new changes to Gerrit targeting those
branches _because_ we can't indefinitely maintain the contemporary
infrastructure required to test them and confirm they work and don't
introduce new regressions. OpenStack upstream development has taken
the approach that everything we officially maintain should be
continuously buildable and testable. Revisiting the other points
means revisiting that decision as well.
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170505/274f0b00/attachment.sig>

More information about the OpenStack-dev mailing list