Re: [openstack-dev] [Ironic] Should we adopt a blueprint design process
Chris Behrens wrote: +1 FWIW we'll have a cross-project workshop at the design summit about tracking incoming features -- covering blueprint proposal, approval and prioritization. We'll discuss extending the -specs repositories experience and see how it fits the whole picture on the long run: http://summit.openstack.org/cfp/details/3 -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Should we adopt a blueprint design process
+1 for me as well, I'd like to have a better way to track incoming features. Also, as part of the migration progress I think that we need a good wiki page explaining the process of how propose a new feature, with a template of what's mandatory to fill out and what is optional. I wouldn't like to have something like nova currently have as its template[1], I don't know what is mandatory there and what's is not, many times you think that you know a way to do something but as you go you then realize that doing it in another way is much better, so I think that in order to propose a new feature we should not assume that the author knows _everything_ at the start. [1] https://github.com/openstack/nova-specs/blob/master/specs/template.rst On Fri, Apr 18, 2014 at 10:25 AM, Thierry Carrez thie...@openstack.org wrote: Chris Behrens wrote: +1 FWIW we'll have a cross-project workshop at the design summit about tracking incoming features -- covering blueprint proposal, approval and prioritization. We'll discuss extending the -specs repositories experience and see how it fits the whole picture on the long run: http://summit.openstack.org/cfp/details/3 But before we do it I think it might worth waiting to see the output of this session that Thierry pointed out. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Should we adopt a blueprint design process
+1 Great idea. many times you think that you know a way to do something but as you go you then realize that doing it in another way is much better, so I think that in order to propose a new feature we should not assume that the author knows _everything_ at the start. Absolutely agree. It would be great to have kind of design stages. 0) Bare idea, feature scope, use cases. 1) Preliminary architecture and API. Here we can start writing and reviewing code. 2) Detailed understanding of architecture and API. Writing code, testing, detailed discussing, debugging. 3) Merging feature into master, debugging. Vladimir Kozhukalov On Fri, Apr 18, 2014 at 2:08 PM, Lucas Alvares Gomes lucasago...@gmail.comwrote: +1 for me as well, I'd like to have a better way to track incoming features. Also, as part of the migration progress I think that we need a good wiki page explaining the process of how propose a new feature, with a template of what's mandatory to fill out and what is optional. I wouldn't like to have something like nova currently have as its template[1], I don't know what is mandatory there and what's is not, many times you think that you know a way to do something but as you go you then realize that doing it in another way is much better, so I think that in order to propose a new feature we should not assume that the author knows _everything_ at the start. [1] https://github.com/openstack/nova-specs/blob/master/specs/template.rst On Fri, Apr 18, 2014 at 10:25 AM, Thierry Carrez thie...@openstack.org wrote: Chris Behrens wrote: +1 FWIW we'll have a cross-project workshop at the design summit about tracking incoming features -- covering blueprint proposal, approval and prioritization. We'll discuss extending the -specs repositories experience and see how it fits the whole picture on the long run: http://summit.openstack.org/cfp/details/3 But before we do it I think it might worth waiting to see the output of this session that Thierry pointed out. ___ 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
Re: [openstack-dev] [Ironic] Should we adopt a blueprint design process
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
Re: [openstack-dev] [Ironic] Should we adopt a blueprint design process
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.comwrote: 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
Re: [openstack-dev] [Ironic] Should we adopt a blueprint design process
+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
