Open Stack

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 ;)

>  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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140713/6c6fe11e/attachment.html>