Open Stack

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

Hi Steve, 

I'm -1 on merging the docs. Regardless of the warnings we put, people are going to be confused seeing features here that they can't use. There is also a huge changes that the implementation will change from the original doc, thus making us forced to update it if/when we merge.

AFAIK gerrit is persistent, so we can keep the doc patch in it forever and link it in a blueprint. And merge the doc change alongside the implementation.

Cheers,

-- 
Thomas