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.math...@gmail.com> wrote: > > On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant > <jsbry...@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.dug...@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.math...@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.dunsm...@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@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
