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