Open Stack

John,

So you have said a few times that the specs are a learning process.
What do you feel with have learned thus far using specs?  I think you
had the hope that it would help organize targeting blueprints and not
missing things for a release.  Do you feel that is working?

I would like to hear more about how you feel this is working.

Personally, initially, having specs made sense given that they are a
better way to spark discussion around a design change.  They were
working well early in the release for that purpose.

Now, however, they have become a point of confusion.  There is the
question of "when is just a BP sufficient" versus when is neither
required.

I think this is part of the learning process.  Just worth having
discussion so we know for the next round what is needed when.

Jay

On Sun, 2014-07-13 at 16:31 -0600, John Griffith wrote:
> 
> 
> 
> 
> On Sun, Jul 13, 2014 at 8:01 AM, Dolph Mathews
> <dolph.mathews at gmail.com> wrote:
>         
>         On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant
>         <jsbryant at electronicjungle.net> wrote:
>                 I had been under the impression that all BPs we going
>                 to require a spec.  I, however,  was made are in
>                 today's cinder meeting that we are only requiring
>                 specs for changes that change the user's interaction
>                 with the system or are a large change that touches the
>                 broader cinder code base.
>                 
>         That's generally where we use blueprints in Keystone, anyway.
>         If the change has no impact on end users, deployers or other
>         projects, then it doesn't need a spec/blueprint. For example,
>         a refactor only affects developers of Keystone, so I'd argue
>         that blueprints are unnecessary.
>         
>         
>         
>         The premise of a "large change that touches the broader ...
>         code base" requiring a blueprint is flawed though - we don't
>         want to review large changes anyway ;)
> 
> 
> ​Just have to say I really like this last point... also even though
> I'm the one who made that statement the problem with it is that it's
> rather subjective.  
> 
> 
> My position is and continues to be that specs are a learning process,
> we're hammering it out and these conversations on the ML are helpful.​
>                 This seemsto make sense to me.  The user's commit
>                 message and unit tests should show the thought of the
>                 changes impact. 
>                 
>                 Jay
>                 
>                 On Jul 9, 2014 7:57 AM, "Dugger, Donald D"
>                 <donald.d.dugger at intel.com> wrote:
>                         Much as I dislike the overhead and the extra
>                         latency involved (now you need to have a
>                         review cycle for the spec plus the review
>                         cycle for the patch itself) I agreed with the
>                         `small features require small specs’.  The
>                         problem is that even a small change can have a
>                         big impact.  Forcing people to create a spec
>                         even for small features means that it’s very
>                         clear that the implications of the feature
>                         have been thought about and addressed.
>                         
>                          
>                         
>                         Note that there is a similar issue with bugs.
>                          I would expect that a patch to fix a bug
>                         would have to have a corresponding bug report.
>                         Just accepting patches with no known
>                         justification seems like the wrong way to go.
>                         
>                          
>                         
>                         --
>                         
>                         Don Dugger
>                         
>                         "Censeo Toto nos in Kansa esse decisse." - D.
>                         Gale
>                         
>                         Ph: 303/443-3786
>                         
>                          
>                         
>                         From: Dolph Mathews
>                         [mailto:dolph.mathews at gmail.com] 
>                         Sent: Tuesday, July 1, 2014 11:02 AM
>                         To: OpenStack Development Mailing List (not
>                         for usage questions)
>                         Subject: Re: [openstack-dev] [all][specs]
>                         Please stop doing specs for any changes in
>                         projects
>                         
>                          
>                         
>                         The argument has been made in the past that
>                         small features will require correspondingly
>                         small specs. If there's a counter-argument to
>                         this example (a "small" feature requiring a
>                         relatively large amount of spec effort), I'd
>                         love to have links to both the spec and the
>                         resulting implementation so we can discuss
>                         exactly why the spec was an unnecessary
>                         additional effort.
>                         
>                         On Tue, Jul 1, 2014 at 10:30 AM, Jason
>                         Dunsmore <jason.dunsmore at rackspace.com> wrote:
>                         
>                                 On Mon, Jun 30 2014, Joshua Harlow
>                                 wrote:
>                                 
>                                 > There is a balance here that needs
>                                 to be worked out and I've seen
>                                 > specs start to turn into
>                                 requirements for every single patch
>                                 (even if
>                                 > the patch is pretty small). I hope
>                                 we can rework the 'balance in the
>                                 > force' to avoid being so strict that
>                                 every little thing requires a
>                                 > spec. This will not end well for us
>                                 as a community.
>                                 >
>                                 > How have others thought the spec
>                                 process has worked out so far? To
>                                 > much overhead, to little…?
>                                 >
>                                 > I personally am of the opinion that
>                                 specs should be used for large
>                                 > topics (defining large is of course
>                                 arbitrary); and I hope we find the
>                                 > right balance to avoid scaring
>                                 everyone away from working with
>                                 > openstack. Maybe all of this is part
>                                 of openstack maturing, I'm not
>                                 > sure, but it'd be great if we could
>                                 have some guidelines around when
>                                 > is a spec needed and when isn't it
>                                 and take it into consideration when
>                                 > requesting a spec that the person
>                                 you have requested may get
>                                 > frustrated and just leave the
>                                 community (and we must not have this
>                                 > happen) if you ask for it without
>                                 explaining why and how clearly.
>                                 
>                                 +1 I think specs are too much overhead
>                                 for small features.  A set of
>                                 guidelines about when specs are needed
>                                 would be sufficient.  Leave the
>                                 option about when to submit a design
>                                 vs. when to submit code to the
>                                 contributor.
>                                 
>                                 Jason
>                                 
>                                 
>                                 _______________________________________________
>                                 OpenStack-dev mailing list
>                                 OpenStack-dev at lists.openstack.org
>                                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>                                 
>                                 
>                          
>                         
>                         
>                         
>                         _______________________________________________
>                         OpenStack-dev mailing list
>                         OpenStack-dev at lists.openstack.org
>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>                         
>                 
>                 _______________________________________________
>                 OpenStack-dev mailing list
>                 OpenStack-dev at lists.openstack.org
>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>                 
>         
>         
>         
>         _______________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.org
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>         
> 
>