+1
> On Apr 17, 2014, at 12:27 PM, Russell Haering <russellhaer...@gmail.com> > wrote: > > 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 <mest...@noironetworks.com> >> wrote: >> On Thu, Apr 17, 2014 at 12:11 PM, Devananda van der Veen >> <devananda....@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@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
