cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Kinsella <>
Subject Maintainer/committer model for CloudStack
Date Fri, 04 May 2012 04:24:19 GMT
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:

 * 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 ( 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.



View raw message