Open Stack

Completely agree.

We're spending too much time discussing features after they're implemented,
which makes contribution more difficult for everyone. Forcing an explicit
design+review process, using the same tools as we use for coding+review
seems like a great idea. If it doesn't work we can iterate.


On Thu, Apr 17, 2014 at 11:01 AM, Kyle Mestery <mestery at noironetworks.com>wrote:

> On Thu, Apr 17, 2014 at 12:11 PM, Devananda van der Veen
> <devananda.vdv at gmail.com> wrote:
> > Hi all,
> >
> > The discussion of blueprint review has come up recently for several
> reasons,
> > not the least of which is that I haven't yet reviewed many of the
> blueprints
> > that have been filed recently.
> >
> > My biggest issue with launchpad blueprints is that they do not provide a
> > usable interface for design iteration prior to writing code. Between the
> > "whiteboard" section, wikis, and etherpads, we have muddled through a few
> > designs (namely cinder and ceilometer integration) with accuracy, but the
> > vast majority of BPs are basically reviewed after they're implemented.
> This
> > seems to be a widespread objection to launchpad blueprints within the
> > OpenStack community, which others are trying to solve. Having now looked
> at
> > what Nova is doing with the nova-specs repo, and considering that
> TripleO is
> > also moving to that format for blueprint submission, and considering
> that we
> > have a very good "review things in gerrit" culture in the Ironic
> community
> > already, I think it would be a very positive change.
> >
> > For reference, here is the Nova discussion thread:
> >
> http://lists.openstack.org/pipermail/openstack-dev/2014-March/029232.html
> >
> > and the specs repo BP template:
> > https://github.com/openstack/nova-specs/blob/master/specs/template.rst
> >
> > So, I would like us to begin using this development process over the
> course
> > of Juno. We have a lot of BPs up right now that are light on details,
> and,
> > rather than iterate on each of them in launchpad, I would like to propose
> > that:
> > * we create an ironic-specs repo, based on Nova's format, before the
> summit
> > * I will begin reviewing BPs leading up to the summit, focusing on
> features
> > that were originally targeted to Icehouse and didn't make it, or are
> > obviously achievable for J1
> > * we'll probably discuss blueprints and milestones at the summit, and
> will
> > probably adjust targets
> > * after the summit, for any BP not targeted to J1, we require blueprint
> > proposals to go through the spec review process before merging any
> > associated code.
> >
> > Cores and interested parties, please reply to this thread with your
> > opinions.
> >
> I think this is a great idea Devananda. The Neutron community has
> moved to this model for Juno as well, and people have been very
> positive so far.
>
> Thanks,
> Kyle
>
> > --
> > Devananda
> >
> > _______________________________________________
> > 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/20140417/10451a79/attachment.html>