Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: unknown mxinclude:zoho.com~all (athena.apache.org: encountered
 unrecognized mechanism during SPF processing of domain of jlk@stratosec.co)
From: John Kinsella <jlk@stratosec.co>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Maintainer/committer model for CloudStack
Date: Thu, 3 May 2012 21:24:19 -0700
Message-Id: <BDA478B2-9CEA-4B6C-9F19-1B8A77DBB8A9@stratosec.co>
To: cloudstack-dev@incubator.apache.org
Mime-Version: 1.0 (Apple Message framework v1084)

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=