<br><br>On Tuesday, July 15, 2014, Jay S. Bryant <<a href="mailto:jsbryant@electronicjungle.net">jsbryant@electronicjungle.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
John,<br>
<br>
So you have said a few times that the specs are a learning process.<br>
What do you feel with have learned thus far using specs?</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div><br></div>- we are inexperienced at doing design work<div>
- we are inexperienced at considering the full impact of a change</div><div>- agreeing on the problem statement is more important than agreeing a solution</div><div>- it's easy to confuse design work with implementation work, and we need to get better at separating the two</div>
<div>- specs more easily allow cross-project collaboration and non-dev stakeholders to provide early feedback when compared to blueprints or implementation changes<span></span></div><div>- specs don't make it easy to compare two solutions to the same problem, but I hope they will</div>
<div>- blueprints are even more cumbersome than ever</div><div>- specs are terrible at tracking work items and assignees</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think you<br>
had the hope that it would help organize targeting blueprints and not<br>
missing things for a release. Do you feel that is working?<br>
<br>
I would like to hear more about how you feel this is working.<br>
<br>
Personally, initially, having specs made sense given that they are a<br>
better way to spark discussion around a design change. They were<br>
working well early in the release for that purpose.<br>
<br>
Now, however, they have become a point of confusion. There is the<br>
question of "when is just a BP sufficient" versus when is neither<br>
required.<br>
<br>
I think this is part of the learning process. Just worth having<br>
discussion so we know for the next round what is needed when.<br>
<br>
Jay<br>
<br>
On Sun, 2014-07-13 at 16:31 -0600, John Griffith wrote:<br>
><br>
><br>
><br>
><br>
> On Sun, Jul 13, 2014 at 8:01 AM, Dolph Mathews<br>
> <<a href="javascript:;" onclick="_e(event, 'cvml', 'dolph.mathews@gmail.com')">dolph.mathews@gmail.com</a>> wrote:<br>
><br>
> On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant<br>
> <<a href="javascript:;" onclick="_e(event, 'cvml', 'jsbryant@electronicjungle.net')">jsbryant@electronicjungle.net</a>> wrote:<br>
> I had been under the impression that all BPs we going<br>
> to require a spec. I, however, was made are in<br>
> today's cinder meeting that we are only requiring<br>
> specs for changes that change the user's interaction<br>
> with the system or are a large change that touches the<br>
> broader cinder code base.<br>
><br>
> That's generally where we use blueprints in Keystone, anyway.<br>
> If the change has no impact on end users, deployers or other<br>
> projects, then it doesn't need a spec/blueprint. For example,<br>
> a refactor only affects developers of Keystone, so I'd argue<br>
> that blueprints are unnecessary.<br>
><br>
><br>
><br>
> The premise of a "large change that touches the broader ...<br>
> code base" requiring a blueprint is flawed though - we don't<br>
> want to review large changes anyway ;)<br>
><br>
><br>
> Just have to say I really like this last point... also even though<br>
> I'm the one who made that statement the problem with it is that it's<br>
> rather subjective.<br>
><br>
><br>
> My position is and continues to be that specs are a learning process,<br>
> we're hammering it out and these conversations on the ML are helpful.<br>
> This seemsto make sense to me. The user's commit<br>
> message and unit tests should show the thought of the<br>
> changes impact.<br>
><br>
> Jay<br>
><br>
> On Jul 9, 2014 7:57 AM, "Dugger, Donald D"<br>
> <<a href="javascript:;" onclick="_e(event, 'cvml', 'donald.d.dugger@intel.com')">donald.d.dugger@intel.com</a>> wrote:<br>
> Much as I dislike the overhead and the extra<br>
> latency involved (now you need to have a<br>
> review cycle for the spec plus the review<br>
> cycle for the patch itself) I agreed with the<br>
> `small features require small specs’. The<br>
> problem is that even a small change can have a<br>
> big impact. Forcing people to create a spec<br>
> even for small features means that it’s very<br>
> clear that the implications of the feature<br>
> have been thought about and addressed.<br>
><br>
><br>
><br>
> Note that there is a similar issue with bugs.<br>
> I would expect that a patch to fix a bug<br>
> would have to have a corresponding bug report.<br>
> Just accepting patches with no known<br>
> justification seems like the wrong way to go.<br>
><br>
><br>
><br>
> --<br>
><br>
> Don Dugger<br>
><br>
> "Censeo Toto nos in Kansa esse decisse." - D.<br>
> Gale<br>
><br>
> Ph: 303/443-3786<br>
><br>
><br>
><br>
> From: Dolph Mathews<br>
> [mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'dolph.mathews@gmail.com')">dolph.mathews@gmail.com</a>]<br>
> Sent: Tuesday, July 1, 2014 11:02 AM<br>
> To: OpenStack Development Mailing List (not<br>
> for usage questions)<br>
> Subject: Re: [openstack-dev] [all][specs]<br>
> Please stop doing specs for any changes in<br>
> projects<br>
><br>
><br>
><br>
> The argument has been made in the past that<br>
> small features will require correspondingly<br>
> small specs. If there's a counter-argument to<br>
> this example (a "small" feature requiring a<br>
> relatively large amount of spec effort), I'd<br>
> love to have links to both the spec and the<br>
> resulting implementation so we can discuss<br>
> exactly why the spec was an unnecessary<br>
> additional effort.<br>
><br>
> On Tue, Jul 1, 2014 at 10:30 AM, Jason<br>
> Dunsmore <<a href="javascript:;" onclick="_e(event, 'cvml', 'jason.dunsmore@rackspace.com')">jason.dunsmore@rackspace.com</a>> wrote:<br>
><br>
> On Mon, Jun 30 2014, Joshua Harlow<br>
> wrote:<br>
><br>
> > There is a balance here that needs<br>
> to be worked out and I've seen<br>
> > specs start to turn into<br>
> requirements for every single patch<br>
> (even if<br>
> > the patch is pretty small). I hope<br>
> we can rework the 'balance in the<br>
> > force' to avoid being so strict that<br>
> every little thing requires a<br>
> > spec. This will not end well for us<br>
> as a community.<br>
> ><br>
> > How have others thought the spec<br>
> process has worked out so far? To<br>
> > much overhead, to little…?<br>
> ><br>
> > I personally am of the opinion that<br>
> specs should be used for large<br>
> > topics (defining large is of course<br>
> arbitrary); and I hope we find the<br>
> > right balance to avoid scaring<br>
> everyone away from working with<br>
> > openstack. Maybe all of this is part<br>
> of openstack maturing, I'm not<br>
> > sure, but it'd be great if we could<br>
> have some guidelines around when<br>
> > is a spec needed and when isn't it<br>
> and take it into consideration when<br>
> > requesting a spec that the person<br>
> you have requested may get<br>
> > frustrated and just leave the<br>
> community (and we must not have this<br>
> > happen) if you ask for it without<br>
> explaining why and how clearly.<br>
><br>
> +1 I think specs are too much overhead<br>
> for small features. A set of<br>
> guidelines about when specs are needed<br>
> would be sufficient. Leave the<br>
> option about when to submit a design<br>
> vs. when to submit code to the<br>
> contributor.<br>
><br>
> Jason<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'OpenStack-dev@lists.openstack.org')">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'OpenStack-dev@lists.openstack.org')">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'OpenStack-dev@lists.openstack.org')">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'OpenStack-dev@lists.openstack.org')">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'OpenStack-dev@lists.openstack.org')">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>