Re: [openstack-dev] [Ironic] Proposal for slight change in our spec process
On August 7, 2014 at 8:36:16 AM, Matt Wagner (matt.wag...@redhat.com) wrote: On 07/08/14 14:17 +0200, Dmitry Tantsur wrote: >2. We'll need to speed up spec reviews, because we're adding one more >blocker on the way to the code being merged :) Maybe it's no longer a >problem actually, we're doing it faster now. I'm not sure if this will actually delay stuff getting merged. It certainly has the potential to do so. If people submit a draft in Launchpad and it takes us a week to review it, that's adding a lot of latency. OTOH, if we're on top of things, I think it could actually increase overall throughput. We'd spent less time reviewing specs that are just entirely out of scope, and we'd be able to help steer spec-writers onto the right path sooner. They, in turn, would waste less time writing specs that are then rejected wholesale, or deemed to need significant reworking. I'm not really disagreeing with you--we need to be vigilant and make sure we don't introduce a bottleneck with this. But I also think that, as long as we do that, we might actually speed things up overall. I agree. I think we have been doing much better with specs, especially since growing that core team and explicitly defining our priorities for Juno. I don’t think this will increase latency in reviews - the initial review is quick and easy to do, as it’s just deciding overall if we want the feature. I think this may actually *reduce* latency - specs that are not wanted will get -2’d quickly, and steps that are wanted will have at least one core that is excited about the feature (if no cores care about the feature, it likely won’t be “pre-approved” or whatever we’re calling it). I +1’d this at the meetup, doing it here again for public consumption. :) // jim -- Matt ___ 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] Proposal for slight change in our spec process
On 07/08/14 14:17 +0200, Dmitry Tantsur wrote: 2. We'll need to speed up spec reviews, because we're adding one more blocker on the way to the code being merged :) Maybe it's no longer a problem actually, we're doing it faster now. I'm not sure if this will actually delay stuff getting merged. It certainly has the potential to do so. If people submit a draft in Launchpad and it takes us a week to review it, that's adding a lot of latency. OTOH, if we're on top of things, I think it could actually increase overall throughput. We'd spent less time reviewing specs that are just entirely out of scope, and we'd be able to help steer spec-writers onto the right path sooner. They, in turn, would waste less time writing specs that are then rejected wholesale, or deemed to need significant reworking. I'm not really disagreeing with you--we need to be vigilant and make sure we don't introduce a bottleneck with this. But I also think that, as long as we do that, we might actually speed things up overall. -- Matt pgpRWLWhQkzZP.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Proposal for slight change in our spec process
Hi! On Tue, 2014-08-05 at 12:33 -0700, Devananda van der Veen wrote: > Hi all! > > > The following idea came out of last week's midcycle for how to improve > our spec process and tracking on launchpad. I think most of us liked > it, but of course, not everyone was there, so I'll attempt to write > out what I recall. > > > This would apply to new specs proposed for Kilo (since the new spec > proposal deadline has already passed for Juno). > > > > > First, create a blueprint in launchpad and populate it with your > spec's heading. Then, propose a spec with just the heading (containing > a link to the BP), Problem Description, and first paragraph outlining > your Proposed change. > > > This will be given an initial, high-level review to determine whether > it is in scope and in alignment with project direction, which will be > reflected on the review comments, and, if affirmed, by setting the > blueprint's "Direction" field to "Approved". How will we formally track it in Gerrit? By having several +1's by spec cores? Or will it be done by you (I guess only you can update "Direction" in LP)? > > > At this point, if affirmed, you should proceed with filling out the > entire spec, and the remainder of the process will continue as it was > during Juno. Once the spec is approved, update launchpad to set the > specification URL to the spec's location on > https://specs.openstack.org/openstack/ironic-specs/ and a member of > the team (probably me) will update the release target, priority, and > status. > > > > > I believe this provides two benefits. First, it should give quicker > initial feedback to proposer if their change is going to be in/out of > scope, which can save considerable time if the proposal is out of > scope. Second, it allows us to track well-aligned specs on Launchpad > before they are completely approved. We observed that several specs > were approved at nearly the same time as the code was approved. Due to > the way we were using LP this cycle, it meant that LP did not reflect > the project's direction in advance of landing code, which is not what > we intended. This may have been confusing, and I think this will help > next cycle. FWIW, several other projects have observed a similar > problem with spec<->launchpad interaction, and are adopting similar > practices for Kilo. > > > > > Comments/discussion welcome! I'm +1 to the idea, just some concerns about the implementation: 1. We don't have any "pre-approved" state in Gerrit - need agreement on when to continue (see above) 2. We'll need to speed up spec reviews, because we're adding one more blocker on the way to the code being merged :) Maybe it's no longer a problem actually, we're doing it faster now. > > > > -Deva > ___ > 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] Proposal for slight change in our spec process
I also am in favor of this. +1 Chris Krelle On Wed, Aug 6, 2014 at 9:04 AM, Jay Faulkner wrote: > Similarly, I appreciated this idea when we discussed it at the mid-cycle > and doing so here. > > +1 > > -Jay Faulkner > > > From: Lucas Alvares Gomes > Sent: Wednesday, August 06, 2014 2:34 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Ironic] Proposal for slight change in our > specprocess > > Already agreed with the idea at the midcycle, but just making it public: +1 > > On Tue, Aug 5, 2014 at 8:54 PM, Roman Prykhodchenko > wrote: > > Hi! > > > > I think this is a nice idea indeed. Do you plan to use this process > starting > > from Juno or as soon as possible? > > It will start in Kilo > > ___ > 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] Proposal for slight change in our spec process
Similarly, I appreciated this idea when we discussed it at the mid-cycle and doing so here. +1 -Jay Faulkner From: Lucas Alvares Gomes Sent: Wednesday, August 06, 2014 2:34 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ironic] Proposal for slight change in our spec process Already agreed with the idea at the midcycle, but just making it public: +1 On Tue, Aug 5, 2014 at 8:54 PM, Roman Prykhodchenko wrote: > Hi! > > I think this is a nice idea indeed. Do you plan to use this process starting > from Juno or as soon as possible? It will start in Kilo ___ 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] Proposal for slight change in our spec process
Already agreed with the idea at the midcycle, but just making it public: +1 On Tue, Aug 5, 2014 at 8:54 PM, Roman Prykhodchenko wrote: > Hi! > > I think this is a nice idea indeed. Do you plan to use this process starting > from Juno or as soon as possible? It will start in Kilo ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Proposal for slight change in our spec process
On 05/08/14 12:33 -0700, Devananda van der Veen wrote: Hi all! The following idea came out of last week's midcycle for how to improve our spec process and tracking on launchpad. I think most of us liked it, but of course, not everyone was there, so I'll attempt to write out what I recall. This would apply to new specs proposed for Kilo (since the new spec proposal deadline has already passed for Juno). First, create a blueprint in launchpad and populate it with your spec's heading. Then, propose a spec with just the heading (containing a link to the BP), Problem Description, and first paragraph outlining your Proposed change. This will be given an initial, high-level review to determine whether it is in scope and in alignment with project direction, which will be reflected on the review comments, and, if affirmed, by setting the blueprint's "Direction" field to "Approved". At this point, if affirmed, you should proceed with filling out the entire spec, and the remainder of the process will continue as it was during Juno. Once the spec is approved, update launchpad to set the specification URL to the spec's location on https://specs.openstack.org/openstack/ironic-specs/ and a member of the team (probably me) will update the release target, priority, and status. I believe this provides two benefits. First, it should give quicker initial feedback to proposer if their change is going to be in/out of scope, which can save considerable time if the proposal is out of scope. Second, it allows us to track well-aligned specs on Launchpad before they are completely approved. We observed that several specs were approved at nearly the same time as the code was approved. Due to the way we were using LP this cycle, it meant that LP did not reflect the project's direction in advance of landing code, which is not what we intended. This may have been confusing, and I think this will help next cycle. FWIW, several other projects have observed a similar problem with spec<->launchpad interaction, and are adopting similar practices for Kilo. Comments/discussion welcome! As someone who has proposed a lengthy spec that was deemed to be out-of-scope (mea culpa!), a big +1 to this idea! :) I think this will also be a good way to catch instances where several people propose similar, overlapping specs. I think we're still in 'laboratories of democracy' status with this, but long-term I hope the various projects can converge on a single protocol for proposing specs. -- Matt pgpu4E8RgLHjT.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Proposal for slight change in our spec process
Hi! I think this is a nice idea indeed. Do you plan to use this process starting from Juno or as soon as possible? - Roman On Aug 5, 2014, at 22:33, Devananda van der Veen wrote: > Hi all! > > The following idea came out of last week's midcycle for how to improve our > spec process and tracking on launchpad. I think most of us liked it, but of > course, not everyone was there, so I'll attempt to write out what I recall. > > This would apply to new specs proposed for Kilo (since the new spec proposal > deadline has already passed for Juno). > > > First, create a blueprint in launchpad and populate it with your spec's > heading. Then, propose a spec with just the heading (containing a link to the > BP), Problem Description, and first paragraph outlining your Proposed change. > > This will be given an initial, high-level review to determine whether it is > in scope and in alignment with project direction, which will be reflected on > the review comments, and, if affirmed, by setting the blueprint's "Direction" > field to "Approved". > > At this point, if affirmed, you should proceed with filling out the entire > spec, and the remainder of the process will continue as it was during Juno. > Once the spec is approved, update launchpad to set the specification URL to > the spec's location on https://specs.openstack.org/openstack/ironic-specs/ > and a member of the team (probably me) will update the release target, > priority, and status. > > > I believe this provides two benefits. First, it should give quicker initial > feedback to proposer if their change is going to be in/out of scope, which > can save considerable time if the proposal is out of scope. Second, it allows > us to track well-aligned specs on Launchpad before they are completely > approved. We observed that several specs were approved at nearly the same > time as the code was approved. Due to the way we were using LP this cycle, it > meant that LP did not reflect the project's direction in advance of landing > code, which is not what we intended. This may have been confusing, and I > think this will help next cycle. FWIW, several other projects have observed a > similar problem with spec<->launchpad interaction, and are adopting similar > practices for Kilo. > > > Comments/discussion welcome! > > -Deva > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] Proposal for slight change in our spec process
Hi all! The following idea came out of last week's midcycle for how to improve our spec process and tracking on launchpad. I think most of us liked it, but of course, not everyone was there, so I'll attempt to write out what I recall. This would apply to new specs proposed for Kilo (since the new spec proposal deadline has already passed for Juno). First, create a blueprint in launchpad and populate it with your spec's heading. Then, propose a spec with just the heading (containing a link to the BP), Problem Description, and first paragraph outlining your Proposed change. This will be given an initial, high-level review to determine whether it is in scope and in alignment with project direction, which will be reflected on the review comments, and, if affirmed, by setting the blueprint's "Direction" field to "Approved". At this point, if affirmed, you should proceed with filling out the entire spec, and the remainder of the process will continue as it was during Juno. Once the spec is approved, update launchpad to set the specification URL to the spec's location on https://specs.openstack.org/openstack/ironic-specs/ and a member of the team (probably me) will update the release target, priority, and status. I believe this provides two benefits. First, it should give quicker initial feedback to proposer if their change is going to be in/out of scope, which can save considerable time if the proposal is out of scope. Second, it allows us to track well-aligned specs on Launchpad before they are completely approved. We observed that several specs were approved at nearly the same time as the code was approved. Due to the way we were using LP this cycle, it meant that LP did not reflect the project's direction in advance of landing code, which is not what we intended. This may have been confusing, and I think this will help next cycle. FWIW, several other projects have observed a similar problem with spec<->launchpad interaction, and are adopting similar practices for Kilo. Comments/discussion welcome! -Deva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
