Open Stack

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?
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.