On Mon, Apr 07, 2014 at 09:30:50AM +0200, Thomas Spatzier wrote: > > From: Steve Baker <[email protected]> > > To: [email protected] > > 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?
IMO patches which add or modify interfaces should always have a blueprint, and generally any patch fixing a user-visible problem should have a bug. Sometimes, if a patch is refactoring, doing cosmetic cleanups, or fixing a non-user-visible problem, I think it's fine to merge it without a BP or a bug, but if we're routinely merging user-visible changes without either, then we need to stop (I don't actually think we are btw..) So perhaps we just communicate a reminder to heat-core that they should pay particular attention to the hot spec (and any other user-visible changes such as additions to the API) to ensure changes are tracked appropriately in launchpad? Steve _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
