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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
