On Tuesday, July 15, 2014, Jay S. Bryant <jsbry...@electronicjungle.net> wrote:
> 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? - we are inexperienced at doing design work - we are inexperienced at considering the full impact of a change - agreeing on the problem statement is more important than agreeing a solution - it's easy to confuse design work with implementation work, and we need to get better at separating the two - specs more easily allow cross-project collaboration and non-dev stakeholders to provide early feedback when compared to blueprints or implementation changes - specs don't make it easy to compare two solutions to the same problem, but I hope they will - blueprints are even more cumbersome than ever - specs are terrible at tracking work items and assignees > 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 <javascript:;>> wrote: > > > > On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant > > <jsbry...@electronicjungle.net <javascript:;>> 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 <javascript:;>> 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 <javascript:;>] > > 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 > <javascript:;>> 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 > <javascript:;> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org <javascript:;> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org <javascript:;> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org <javascript:;> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org <javascript:;> > 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