cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <>
Subject Re: Maintainer/committer model for CloudStack
Date Mon, 07 May 2012 18:23:26 GMT

On May 7, 2012, at 11:06 AM, Frank Zhang wrote:

>> On May 4, 2012, at 8:37 AM, David Nalley wrote:
>>> 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,
>> 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.
> I also agree the model  of maintainer of module. One maintainer for each module should
be good enough 
> but there must be another person having privilege to commit patch in case the maintainer
is travelling or on vacation.
> The super maintainer who has knowledge of the whole system needs not to involve in daily
patches committing work,
> once there is a big patch that crosses multiple sub modules, super maintainer joins in
discussion to help sub maintainer 
> to identify if the patch is good enough to check in.

Never send a big patch that changes multiple modules, separate into multiple small patches
instead, make maintainer's life easier.

>>>> * 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.
> For developing a new feature, I am sure in addition to maintainer there would be quite
a few people joining in
> vote or discussion. For bug fix especially small bug fix, if no others throw out opposed
idea,  maintainer can
> commit the patch directly if he agrees with it
>>>> * 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
> Absolutely. 
>>>> 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.
>> What might work is for smaller or less critical modules a single maintainer is
>> OK, but PMC has ability to specify certain modules have multiple maintainers?
>> That could provide flexibility to minimize overhead on some parts. Wouldn't
>> want to make a module seem less important, though...
>>> * 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
>> I'm not sure about the regular rotation part - when I think of the large OSS
>> projects, the maintainers have been in place for years...rotation requires
>> getting somebody else up to speed?
>>> 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'm willing to take a stab, happy to work with others...
>>> 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.
>> Sorry, I left this off the initial email, wasn't sure if it was within scope of the
>> discussion. Browsing through, it
>> looks like most projects branch either for feature dev or version branches...
>> Just found
>> while browsing - I can see borrowing from that. :) Voting on releases also
>> makes sense.
>> John

View raw message