OpenStack Compute Tech Lead Russell Bryant has triggered an important discussion on the OpenStack Development mailing list about the process to review blueprints. The Blueprints wiki page currently assigns to Project Tech Leads the task of assigning priority to the blueprints and Russell is suggesting that a wider group of people in the community shares such responsibility..
Blueprints are used by project leaders to track development of significant features in all OpenStack programs: a blueprint is made of a title and a brief description, plus a URL to a wider description of architecture and specifications (usually a wiki or etherpad page). Given the growing size of OpenStack code base, scaling development operations is increasingly hard and one person cannot handle reviewing all the proposed blueprints and set priorities in a way that guarantees finalization.
This brings us to the second issue that needs to be addressed: managing expectations of new contributors. With so many blueprints being proposed it’s hard for a PTL to be accountable for developers to deliver the code based on blueprint’s priorities. Since the PTL used to set the priority for the blueprint, it is hard to held him/her accountable when the code is not delivered accordingly. There is clearly a separation of powers between the person evaluating the blueprints, the developers that will implement them and the reviewers that will review the code submitted.
Russell’s proposal is to assign the responsibility to review the blueprints to the same team of people that will be responsible for reviewing and approving the code during the implementation phase, the core reviewers. The role of the PTL will still be to set the deadlines for the blueprints and to make sure that the roadmap for the program is sound. The core reviewers will then be sharing with the PTL the responsibility and accountability for the deliverables at each release milestone
In the discussion that’s following on the mailing list there are also proposals to include user input while setting the priorities for blueprints. There are risks also associated with this setup. So far, the process has been discussed only taking into account the needs of OpenStack Compute. The project is the largest OpenStack project by number of blueprints, making it the first to need reviewing the existing process. However, the expectation is that several other OpenStack projects may evolve to this point in the future and this is an important test for that time. As such, we welcome holistic feedback: join the discussion on the development mailing list and in Hong Kong.
Leave a Reply