On Fri, May 4, 2012 at 12:24 AM, John Kinsella <j...@stratosec.co> wrote: > 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
Thanks for starting the discussion John and bringing all of this back to the mailing list. I am a fan of the module maintainer method - but I think that it has some weaknesses - not necessarily unworkable, but things we should at least acknowledge if we think module maintainer is the way we begin to handle things. Namely: * Tends to result in SPOF - may need some mitigation strategies. * Need to ensure that it's not seen as authority or a place where decisions are made, but rather as a place of responsibility - with those responsibilities being the occasionally competing demands of getting changes in and maintaining quality. * This needs to be rotated regularly Of course, at best, these could only be informal rules - any committer could commit to anything in the repo. Anyone want to draft a proposal for us to try out? I am also interested in some other workflow pieces. How do we do feature development (topic branches in git strike me as a good idea), how do we handle patches, etc. --David
