Open Stack

Excerpts from Tung Doan's message of 2018-06-21 00:35:38 +0200:
>  I agree with Bobh. Considering both Heat Translator and Tosca Parser under
> the management of Tacker could affect other projects. We have recently
> announced OpenStack Apmec [1] (MEC Orchestration Service) which
> consumed these two projects as well.
> In case Heat PTL does not have enough bandwidth to take care of the release
> of these two projects. I just wonder whether it is reasonable to release
> them when having only the approval of their PTL.
> 
> [1] https://github.com/openstack/apmec/tree/master/apmec

According to
https://governance.openstack.org/tc/reference/projects/heat.html the
Heat PTL *is* the PTL for heat-translators. Any internal team structure
that implies otherwise is just that, an internal team structure.

I'm really unclear on what the problem is here. The PTL requested a
release; it looked fine; I approved it; it was completed.

The release team tries to facilitate releases happening as quickly
as possible so we don't block work anyone else is trying to do.
There was no apparent reason to wait for this one.  If the teams
using heat-translator want to coordinate on when releases happen
for some reason, then please deal with that before requesting the
releases (and use a W-1 on the patch if you want us to hold off
until you get approval).  The release team has said we do not want
to have to keep up with separate liaisons for individual deliverables
because it's too much to for us to track.

In the mean time, releases are cheap and we can have as many of
them as we want, so if there are additional features in the pipeline
that will be ready to be released soon we can just do that when
they merge.

And if changes are going into heat-translator that might break
consuming projects, we should deal with that the way we do in other
libraries and set up cross-project gating to try to catch the
problems ahead of time. (Maybe that testing is already in place?)
We can also use the constraint system to block "bad" releases if
they do happen. But it's generally better for us to be releasing
libraries and tools as often as possible, so that any breaking
changes come as part of a small set and so new features are available
shortly after they are implemented.

Doug