Open Stack

On Sun, Apr 06, 2014 at 11:23:28AM -0700, 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.

I agree with Steve Baker here, I think the first step is to get an approved
blueprint, with discussion before approval if needed, then the second step
is the review (which should be primarily to evaluate the implemenation, not
discuss the feature IMO).

I do understand the motivation of what you're proposing, and in general I
think it's already happening informally - I generally just +1 any change
where I think it's controversial (or sometimes +2 with no +A if it's been
posted for a while and looks nearly ready to merge)

So how about:
- All hot spec functional changes must have an associated blueprint
- Where discussion is required, the blueprint can link a wiki page and we
  can discuss on the ML, during this phase the BP will be unapproved and in
  "Discussion" state for definition.
- heat-core should never approve any functional changes to the hot spec
  without an *approved* associated blueprint
- heat-core should never approve any functional change to the hot spec
  without positive feedback from a significant subset of the core team

On the last point, I think it's largely down to common sense along with the
existing process - if we've got feedback from many folks during the review
iterations, I personally don't think we need to strictly enforce 5*+2's on
the final patch, if e.g some minor change was needed in the final
iteration but overall the change has had feedback indicating consensus.

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

IMO we should not merge documentation/spec changes before the
implementation.  There should be a series of patches implementing the
feature, which ends with a documentation update to the spec and template
guide.

I think the place for documenting functionality which we want but is not
yet implemented is the blueprint, or a wiki page linked from the blueprint.

The review process should cater for this already IMO, if we only approve
HOT patches with approved blueprints (which sufficiently define the new
interface), and don't merge patches changing implementation affecting the
HOT interfaces unless an associated docs/spec patch is also posted at the
same time (or even the same patch if it's a simple change).

Steve