Open Stack

> From: Steve Baker <sbaker at redhat.com>
> To: openstack-dev at lists.openstack.org
> Date: 06/04/2014 22:32
> Subject: Re: [openstack-dev] [heat] Managing changes to the Hot
> Specification (hot_spec.rst)
>
> On 07/04/14 06:23, Steven Dake wrote:
> > Hi folks,
> >
> > There are two problems we should address regarding the growth and
> > change to the HOT specification.
> >
> > First our +2/+A process for normal changes doesn't totally make sense
> > for hot_spec.rst.  We generally have some informal bar for
> > controversial changes (of which changes to hot_spec.rst is generally
> > considered:).  I would suggest raising the bar on hot_spec.rst to
> > at-least what is required for a heat-core team addition (currently 5
> > approval votes).  This gives folks plenty of time to review and make
> > sure the heat core team is committed to the changes, rather then a
> > very small 2 member subset.  Of course a -2 vote from any heat-core
> > would terminate the review as usual.
> >
> > Second, There is a window where we say "hey we want this sweet new
> > functionality" yet it remains "unimplemented".  I suggest we create
> > some special tag for these intrinsics/sections/features, so folks know
> > they are unimplemented and NOT officially part of the specification
> > until that is the case.
> >
> > We can call this tag something simple like
> > "*standardization_pending_implementation* for each section which is
> > unimplemented.  A review which proposes this semantic is here:
> > https://review.openstack.org/85610
> >
> > My goal is not to add more review work to people's time, but I really
> > believe any changes to the HOT specification have a profound impact on
> > all things Heat, and we should take special care when considering
> > these changes.
> >
> > Thoughts or concerns?

So in general, I think that might be a good approach, since doing this thru
gerrit reviews seems to work pretty efficiently.
However, we must be careful to really not confuse users, never forget to
update the flags (probably by ensuring during in the feature implementation
patches that the flag is removed), etc.

> How about we just use the existing blueprint approval process for
> changes to the HOT spec? The PTL can make the call whether the change
> can be approved by the PTL or whether it requires discussion and
> consensus first.

I'm just a normal Heater (no core) so might not have the right level of
insight into the process, but to me it looked like the relation between BPs
and patches is not 100% strict. I.e. even if BPs exist but are in a
somewhat abstract shape, changes get in, or changes get in without BPs. So
for the BP-based approach to work, this would have to be handled more
tightly. ... but I'm not suggesting unpragmatic development processes here,
maybe just apply this to hot_spec?

What I like about sdake's approach is the gerrit reviews.

Regards,
Thomas

>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>