[openstack-dev] [Ironic] Proposal for slight change in our spec process

Roman Prykhodchenko rprikhodchenko at mirantis.com
Tue Aug 5 19:54:09 UTC 2014


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 <devananda.vdv at gmail.com> 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 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/20140805/51eb87ae/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140805/51eb87ae/attachment.pgp>


More information about the OpenStack-dev mailing list