From: armando-migliaccio Date: Thu, 15 Oct 2015 23:54:17 +0000 (-0700) Subject: Improvements to the blueprint management process X-Git-Url: https://review.fuel-infra.org/gitweb?a=commitdiff_plain;h=74c236ac3884e65c34fdf3410ca8d9d3c9d3afd6;p=openstack-build%2Fneutron-build.git Improvements to the blueprint management process It is easy to oversubscribe ourselves during a release cycle. We approve specs only to experience that we fail to review consistently; code is posted last minute, we get lost into chasing race conditions, the odd dependency throws the gate under the bus, and the ever-present cosmetic refactoring patch steers our attention from what matters, which is *reviewing what we commit to deliver*. In order to keep ourselves focused on the bigger picture, this patch proposes/formalizes changes to the way we register blueprints so that we can improve our ability to better foresee what we'll deliver at the end of a release. We obviously can't predict the future or chain people to a desk, but a regular pulse check of a well planned task list should at least help mitigate the feeding frenzy that usually happens closer to FF. That inevitably leads to half-baked and buggy solutions. Change-Id: Ia27b2a779204bf98c1dec2a30d00507de285f801 --- diff --git a/doc/source/policies/blueprints.rst b/doc/source/policies/blueprints.rst index 72a6a4d84..30a8c07d1 100644 --- a/doc/source/policies/blueprints.rst +++ b/doc/source/policies/blueprints.rst @@ -2,16 +2,16 @@ Blueprints and Specs ==================== The Neutron team uses the `neutron-specs -`_ repository for it's +`_ repository for its specification reviews. Detailed information can be found `here `_. Please also find additional information in the reviews.rst file. -The Neutron team does not enforce deadlines for specs and blueprints. These -can be submitted throughout the release cycle. The drivers team will review -this on a regular basis throughout the release, and based on the load for the -milestones, will assign these into milestones or move them to the backlog -for selection into a future release. +The Neutron team does not enforce deadlines for specs. These can be submitted +throughout the release cycle. The drivers team will review this on a regular +basis throughout the release, and based on the load for the milestones, will +assign these into milestones or move them to the backlog for selection into +a future release. Please note that we use a `template `_ @@ -19,22 +19,6 @@ for spec submissions. It is not required to fill out all sections in the template. Review of the spec may require filling in information left out by the submitter. -Neutron BP and Spec Notes -------------------------- - -There are occasions when a spec will be approved and the code will not land in -the cycle it was targeted at. For these cases, the work flow to get the spec -into the next release is as follows: - -* The PTL will create a -backlog directory during the RC window and - move all specs which didn't make the there. -* Anyone can propose a patch to neutron-specs which moves a spec from the - previous release into the new release directory. - -The specs which are moved in this way can be fast-tracked into the next -release. Please note that it is required to re-propose the spec for the new -release however. - Neutron Request for Feature Enhancements ---------------------------------------- @@ -79,8 +63,57 @@ The workflow for the life an RFE in Launchpad is as follows: and as a landing page for the spec document, as available on `specs.o.o. `_. The blueprint will then be linked to the original RFE bug report. This step will ensure higher visibility of the RFE over smaller RFEs (in scope) - and consistency accross the various fields required during the blueprint - registration process (Approver, Drafter, etc.). + and consistency across the various fields required during the blueprint + registration process (Approver, Drafter, etc.). More precisely, the + blueprint submitter will work with the RFE submitter to identify the + following: + + * Drafter: who is going to submit and iterate on the spec proposal; he/she + may be the RFE submitter. + * Assignee: who is going to develop the bulk of the code, or the + go-to contributor, if more people are involved. Typically this is + the RFE submitter, but not necessarily. + * Approver: a member of the Neutron team who can commit enough time + during the ongoing release cycle to ensure that code posted for review + does not languish, and that all aspects of the feature development are + taken care of (client, server changes and/or support from other projects + if needed - tempest, nova, openstack-infra, devstack, etc.), as well as + comprehensive testing. + This is typically a core member who has enough experience with what it + takes to get code merged, but other resources amongst the wider team can + also be identified. Approvers are volunteers who show a specific interest + in the blueprint specification, and have enough insight in the area of + work so that they can make effective code reviews and provide design + feedback. An approver will not work in isolation, as he/she can and will + reach out for help to get the job done; however he/she is the main + point of contact with the following responsibilities: + + * Pair up with the drafter/assignee in order to help skip development + blockers. + * Review patches associated with the blueprint: approver and assignee + should touch base regularly and ping each other when new code is + available for review, or if review feedback goes unaddressed. + * Reach out to other reviewers for feedback in areas that may step + out of the zone of her/his confidence. + * Escalate issues, and raise warnings to the release team/PTL if the + effort shows slow progress. Approver and assignee are key parts to land + a blueprint: should the approver and/or assignee be unable to continue + the committment during the release cycle, it is the Approver's + responsibility to reach out the release team/PTL so that replacements + can be identified. + * Provide a status update during the Neutron IRC meeting, if required. + + Approver `assignments `_ + must be carefully identified to ensure that no-one overcommits. A + Neutron contributor develops code himself/herself, and if he/she is an + approver of more than a couple of blueprints in a single cycle/milestone + (depending on the complexity of the spec), it may mean that he/she is + clearly oversubscribed. + The Neutron team will review the status of blueprints targeted for the + milestone during their weekly meeting to ensure a smooth progression of + the work planned. Blueprints for which resources cannot be identified + will have to be deferred. + * In either case (a spec being required or not), once discussion has happened the bug will get an assignee, priority and milestone. * At this point, the RFE is 'approved', and its tag will move from 'rfe' to @@ -162,3 +195,20 @@ questions: Once you are happy with what you wrote, add 'rfe' as tag, and submit. Do not worry, we are here to help you get it right! Happy hacking. + + +Missing your target +------------------- + +There are occasions when a spec will be approved and the code will not land in +the cycle it was targeted at. For these cases, the work flow to get the spec +into the next release is as follows: + +* The PTL will create a -backlog directory during the RC window and + move all specs which didn't make the there. +* Anyone can propose a patch to neutron-specs which moves a spec from the + previous release into the new release directory. + +The specs which are moved in this way can be fast-tracked into the next +release. Please note that it is required to re-propose the spec for the new +release.