Open Stack

Lieutenants

The number of people contributing code to nova has grown dramatically over the last few months, and it is becoming difficult to maintain a clear picture of the entire code base.  I'd like to move towards a somewhat more sectioned view of the code, where there is at least one person who is responsible for maintaining a given section of code.   This is similar to the process [http://p2pfoundation.net/Linux_-_Governance#Linux_Organization] used for linux development.

Since it isn't exactly clear who should be the point of contact for each section of the code, the first step is to collect a list of interested parties.  We have a list that maps core members to areas that they are interested in at http://wiki.openstack.org/NovaCore

I've created a wiki page at http://wiki.openstack.org/NovaLieutenants to start collecting interested parties.  If you feel like you would be a contact point for one of the items on the list, please put your name and contact info in that section.  For now I can work with all of the self-selected contact points on the list.  Ultimately, as PTL, I would like to work towards having a single trusted person for each section of the code to manage commits in that area.

These lieutenants will also give us people to act as PTLs for the new projects when we split off sections (like Network and Volume) into their own services.

Team Contact

I'm also trying to compile a list of all of the different teams working on Nova.  This will allow me to keep track of the development work being done by the various groups.  It would really help if all of the teams could add themselves to this list and select a point of contact for me to communicate with.  Hopefully we can link all of the blueprints on the teams launchpad page, but if you can put a brief overview of the current development effort(s) for your team on the wiki page, that will make it easier for people to see what is being actively worked on at a glance.

The team page is at http://wiki.openstack.org/NovaTeams

Blueprints

I'm currently going through the 40+ Blueprints and organizing them for the design summit.  For the last set of releases there wasn't a whole lot of insight into what makes a blueprint "approved" and what being "approved" means.  The process we're going through now is simply to approve blueprints for discussion at the summit.  The purpose of the summit is to hash out the details of the blueprint, argue about alternative solutions and generally to decide whether it is a good idea.  The hope is that there will be a general consensus amongst the developers at the summit as to whether development should move forward along the lines proposed in the blueprint.

My job as PTL will be to asses this consensus and approve the blueprints which everyone supports.  If there is a great amount of controversy about a particular blueprint, I will likely bring it to a vote by nova-core.  I will only attempt to dictate a direction when consensus is impossible.

Some of the blueprints are smallish features and may not warrant a discussion on their own.  I will attempt to group these where possible into related feature sets so that we can talk about them all at once.  Extremely small features may not warrant a discussion at all, and I may just throw them into the mailing list for feedback before approving them.  I am also working with the various groups that have proposed very related features (like the NaaS proposals) to try to come together and standardize on one blueprint.

To clarify, as far as I'm concerned, it is not required to have an approved blueprint to work on a feature.  If the consensus is against a blueprint and a team/person still thinks it is valuable, the team is more than welcome to develop the feature and propose it for merge.  It will likely take a really killer implementation to swing popular opinion in favor of the feature, but sometimes code trumps design.  It is, however, highly recommended to follow the blueprint process as much as possible.  That way I can track the features being added by different groups and ensure that work is not duplicated and that all the features will play nice together.


Vish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110417/85b365ed/attachment.html>