Open Stack

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 <
doug at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180621/2a2012fe/attachment.html>