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