Hi Doug, I posted in wrong thread :) Sorry for that. The right one is http://lists.openstack.org/pipermail/openstack-dev/2018-June/131688.html
Vào Th 5, 21 thg 6, 2018 vào lúc 01:00 Doug Hellmann < d...@doughellmann.com> đã viết: > 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 >
__________________________________________________________________________ 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
