Open Stack

On Wed, Jul 2, 2014 at 7:08 AM, Lingxian Kong <anlin.kong at gmail.com> wrote:

> IMO, 'spec' is indeed a good idea and indeed useful for tracking
> features, although it's a little tough for us not using English as
> native language. But we still need to identify these 'small features',
> and core reviewers do some review, then approve them ASAP, so that we
> can avoid to waste a lot of time to wait for code implementaion.
>

If you are confident in the acceptability of your spec, I don't think you
should necessarily wait to begin work on an implementation. In fact, I'd
suggest that you not wait at all.

An implementation can help illustrate a spec, find it's weak points, or
even identify unimplementable parts of a spec.

That said, you should maintain such an implementation in Gerrit as a Work
In Progress so that it is not accidentally merged ahead of the spec.


>
> 2014-07-02 2:08 GMT+08:00 Devananda van der Veen <devananda.vdv at gmail.com
> >:
> > On Tue, Jul 1, 2014 at 10:02 AM, Dolph Mathews <dolph.mathews at gmail.com>
> wrote:
> >> 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
> >>>
> >
> > Yes, there needs to be balance, but as far as I have seen, folks are
> > finding the balance around when to require specs within each of the
> > project teams. I am curious if there are any specific examples where a
> > project's core team required a "large spec" for what they considered
> > to be a "small feature".
> >
> > I also feel strongly that the spec process has been very helpful for
> > the projects that I'm involved in for fleshing out the implications of
> > changes which may at first glance seem small, by requiring both
> > proposers and reviewers to think about and discuss the wider
> > ramifications for changes in a way that simply reviewing code often
> > does not.
> >
> > Just my 2c,
> > Devananda
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Regards!
> -----------------------------------
> Lingxian Kong
>
> _______________________________________________
> 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/20140702/3f226481/attachment-0001.html>