incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: Maintainer/committer model for CloudStack
Date Fri, 04 May 2012 15:37:10 GMT
On Fri, May 4, 2012 at 12:24 AM, John Kinsella <> 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 ( 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.


View raw message