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