[openstack-dev] [all][specs] Please stop doing specs for any changes in projects
Dolph Mathews
dolph.mathews at gmail.com
Wed Jul 16 04:14:14 UTC 2014
On Tuesday, July 15, 2014, Jay S. Bryant <jsbryant at 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.mathews at gmail.com <javascript:;>> wrote:
> >
> > On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant
> > <jsbryant at 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.dugger at 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.mathews at 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.dunsmore at 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 at lists.openstack.org
> <javascript:;>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org <javascript:;>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org <javascript:;>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org <javascript:;>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org <javascript:;>
> 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/20140715/5183da4b/attachment.html>
More information about the OpenStack-dev
mailing list