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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
