Open Stack

On Mon, Apr 07, 2014 at 09:30:50AM +0200, Thomas Spatzier wrote:
> > From: Steve Baker <sbaker at redhat.com>
> > To: openstack-dev at lists.openstack.org
> > 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