Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Date: Fri, 4 May 2012 17:45:59 -0500
From: Matt Domsch <Matt_Domsch@dell.com>
To: "cloudstack-dev@incubator.apache.org"
 <cloudstack-dev@incubator.apache.org>
Subject: Re: Maintainer/committer model for CloudStack
Message-ID: <20120504224559.GB1254@emperor.us.dell.com>
References: <BDA478B2-9CEA-4B6C-9F19-1B8A77DBB8A9@stratosec.co>
 <CAKprHVY9AwRBqpKGJTpOKqr463hXoREEp2V6eLAGLx2VCS39+g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAKprHVY9AwRBqpKGJTpOKqr463hXoREEp2V6eLAGLx2VCS39+g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Fri, May 04, 2012 at 10:37:10AM -0500, David Nalley wrote:
> On Fri, May 4, 2012 at 12:24 AM, John Kinsella <jlk@stratosec.co> wrote:
> > 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.

As David pointed out in the live conversation, Fedora has done well
with this "provenpackager" model, where some long-term contributors
who do work all over the tree (or to many packages) can be granted the
right to change (nearly) any package.  As long as the people granted
this power recognize the awesome responsibility it provides, and treat
it appropriately, it works quite well while providing the flexibility
to "get things done" that otherwise would languish waiting on tens of
other individuals to do their small part.  I would want to see CS
retain this capability, though used sparingly.

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

To me, it's not about the number of maintainers of a given module
(only 1, no more than N, ...), it's that each maintainer treat the
role with the respect it deserves, and can work well with the rest of
the maintainers.  David used the word "responsibility" - and I agree.
A strong sense of ownership, of responsibility to the other developers
and the user community, that the code will work, be of high quality,
will be open to suggestions and patches from non-maintainers, and can
mentor non-maintainers into productive recurring contributors or
maintainers going forward.

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

There are 2 parts here: 1) who is the voting audience; 2) what are the
criteria necessary to invoke a vote?  If the above maintainer
ownership responsibility is handled appropriately, there should be no
need for explicit votes (and certainly not for each patch or even
minor patch series).  I'd prefer to see consensus develop for feature
and architecture direction, and leave voting out as much as possible.
Voting for PMC members etc. is appropriate of course, and should be
from a wide audience.  I still need to understand how Apache
membership works in detail, but at a glance, that seems overly
restrictive.  Again looking at Fedodra, we use a "Signed CLA +
contributor to one other group" as the voter pool.  We could look at
something similar for CS.


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

comments within 2 weeks from a maintainer seems appropriate.
application/rejection may not be given other workflows into the tree
and other maintainer responsibilities elsewhere.  Certainly a worthy goal.


> > �* 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

and for the contributor. :-)


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

With the above (min 1 maintainer /module + developers with global
commit power) can mitigate this to a large extent I think.  Any more
than that and you're optimizing for what should be a rare occurance.

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

+1

> * This needs to be rotated regularly

by some definition of regularly, perhaps.  Once we decide on the
qualifications for a maintainer, it should be pretty obvious what a
reasonable timeframe for the role will be.

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

+1 to topic branches and private git trees to pull from.

Thanks,
Matt

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO