Guys - during the developer on-ramp this week, we held a group discussion around the topics of reviewing patch submissions, code maintainers, voting, and overall care and management of the official source tree. We wanted to continue the discussion on the developer list to look for the best way to set this up for CloudStack and I volunteered to kick off the discussion.
For the overall scope of the discussion, I'm using "maintainer" to describe a person who has been given commit rights to trunk, and who reviews potential code modifications for inclusion into the CloudStack source. This is a separate responsibility from that of setting direction and priorities for the CS project. Just want to be clear. :) I'm going to list out some of the points and goals we discussed, but this probably isn't a complete list of things we should be considering: Goals: * Responsive maintainer team that nurtures involvement from the community by providing friendly, useful, efficient responses to code modification submissions * Responsibility vs authority - the goal is not to grant authority to maintain the codebase, but to culture responsibility and respect for the codebase and the community. Points to consider: * Maintainer scope: Is a maintainer responsible for certain parts of CS, or the overall codebase? As CS moves to a more modular architecture, maybe a maintainer focuses on a particular module? The concept of "super" maintainers was mentioned, a select group of people who have the ability to effect change across the entire code base. That one has such ability does not mean that it should be wielded often. * Single or multiple maintainers: Be there a given scope for a module, sub-project, or whatever, CS could adopt a model of a single "ultimate" maintainer who has to do all reviews/commits, or a team of maintainers. The single person model provides "ultimate" responsibility for that scope and a more predictable response to submissions, while a team distributes the workload and minimizes the impact of a single person becoming sick/distracted/trapped under bus/etc. * Code modification voting: General process for Apache projects is to vote +1/0/-1. Question is, when do we use this? It probably isn't necessary for a 3 line commit. * Responsiveness to patch submissions: One option to ensure prompt response to patch submissions would be to have some form of guidance similar to "maintainers will review and respond to patch submissions within 5 days" (pick a number). This isn't really enforceable as the community is neither employed by nor reports to a single entity, although repeated failures to meet the guideline could result in removal from the maintainer position. * Patch testing: It would be great to have a test suite for a maintainer to easily confirm that a patch does not inadvertently affect functionality/logic outside the intended scope of the patch What have I left out? We referenced both the Linux (I can't find a good page describing their process?) and Drupal (http://drupal.org/contribute/core-maintainers) maintenance methods, but open to any others we can look at. Please give any thoughts on the subject, and definitely add any viewpoints/experiences/concepts that you may have. Thanks! John
