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
