On May 4, 2012, at 8:37 AM, David Nalley wrote: > On Fri, May 4, 2012 at 12:24 AM, John Kinsella <j...@stratosec.co> 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 >> (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 > > 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 https://git-wip-us.apache.org/repos/asf, it looks like most projects branch either for feature dev or version branches... Just found http://incubator.apache.org/isis/docbkx/html/guide/pt03.html while browsing - I can see borrowing from that. :) Voting on releases also makes sense. John
