Hey Martin, On Jul 31, 2012, at 10:21 AM, Martin Desruisseaux wrote:
> Le 31/07/12 18:36, Mattmann, Chris A (388J) a écrit : >> My personal 2c is that if folks are doing any of the following enough: >> >> * adding patches >> * creating JIRA issues >> * having thoughtful discussion on list >> * writing documentation >> * answering user questions >> >> or being generally "interested" in the project, then they are a candidate, >> at least for me, >> for committership and PPMC membership on the project. PPMC membership and >> committership is not just for code. Contributions come in many forms. > > Understood. I would bring the point of view that Distributed Versionning > System, through "push" and "pull" actions, can been seen as a more powerful > way to submit patches than email. Yeah to me honestly it's just a discussion of tooling. I've seen SVN + Review Board fulfill a "Github like" capability pretty well, and then the other basic tenets, e.g., Mailing lists, Wiki, CI systems (Jenkins, Buildbot, etc.) work combined with either SVN or Git. Regardless of your preferred tool and/or workflow, the ASF has the ability to support that. > > One thing I could do is to create a Git repository synchronized on the SIS > subversion repository (I'm already doing that for GeoAPI). Using the Git > repository for creating patches would be easier for me, even if the patch is > sent by email for application on SVN, and may be an opportunity for those who > wish to get familiar with Distributed Versionning System. My past experience > with a very large and complex project on SVN convinced me on the importance > of DVS flexibility... Sure, the ASF maintains read-only Git mirrors, here: http://git.apache.org/ Currently I don't believe we have a Git mirror set up for SIS, but it's as simple as filing an issue here: https://issues.apache.org/jira/browse/INFRA And requesting one from infra. ASF Git mirrors are mirrored out to Github and can be used to work on changes, and then post back diffs through git-svn etc etc. The danger though is that we have to be mindful not to split the development communities of ASF repositories. If dev occurs elsewhere, and then is "flushed" back to the list in the form of huge patches representing changes made somewhere else (your laptop, Github, etc.) besides the ASF, with a tool like Git, it's harder to integrate the patches unless they are incremental, and we also lose out on not just the revision history, but also the principle tenets of the Apache way, which is that all conversations must occur on list, including our tooling and infrastructure that sends mails to our mail archives, that can be referenced later. Anyways I'm not really against Git, so if we want to start out with a Git mirror, and then you could use that to develop and submit patches back to SVN and JIRA I'm willing to work with you on those issues and to start incrementally improving SIS and making you a contributor with your vast spatial knowledge and existing GeoTk experience! > > While I agree on the importance of welcoming new members, isn't important to > list what we think developers should know before getting commit rights for a > particular module? For example I would like a page explaining that before > committing in the "referencing" module, we pledge the developer to become > familiar with java.awt.geom.AffineTransform. Even if the committer rarely > touch directly any affine transform, the "spirit" of affine transform is > widely spread across the referencing module and developers often take a while > to become used to it. When patches are sent by email or by a DVS system, the > maintainer having commit right can ensure that the "spirit" of affine > transform is followed. Well that's the thing. There is no single maintainer here of modules at the ASF. We have Project Management Committees who themselves are responsible for the collective "whole" of code, including potentially multiple modules and projects. Now, that being said, the way it turns out is most of the time like you mention above, that a particular PPMC member/committer has itches that they like to scratch and thus modules and code that they really know, whilst other code that they don't. In these cases, rather than having explicit pedagogy to draw a wall between who is good at what, and what others have the "right" to maintain and work on, in my experience, if you trust someone enough to give them the commit bit and add them to the PPMC you trust them implicitly enough to *not* mess with code and/or things that they aren't familiar with. This isn't a 100% always effective solution, and sure there are corner cases, but more often than not, the social and intellectual freedom given, as well as the "good will" earned by trusting people far outweighs people that are malicious and others "messing up" code. Plus, we use a revision control system; things are easy to revert; CI is available to us in all forms, and we have some of the most diverse use cases and people in the world working on code here. In other words, *we care*. Our metrics at Apache that we use to measure this include: * are you adding new committers to a project on a regular basis? * are you releasing the code on a regular basis? * is the code compatible with the Apache license? Those are some loose metrics that, if we are following them, and also following in the social spirit of the ASF, I've found to be very effective in ensuring the quality of projects here. We have some of the most high quality projects in the world, that operate in this manner. That being said, if someone on the PPMC is constantly breaking things, etc., we also have the ability to discuss that on list and to talk through why/where/how to get better/etc. The Apache Board, and the chairs of the PMCs (and PMCs themselves) have broad ability to *fix* problematic situations as well. That's part of what the foundation ensures through its active triage and monitoring of projects. We don't just dump code here, or commit things that don't work (at least for long). Also, we can employ things like branches, and trunk and other techniques at the CM level here to help ensure quality of code and so forth. > But once a developer get direct commit right, I would feel reassured if I > could be confident that AffineTransform has been well understood by him... Of > course this is our responsibility to write a page explaining what we think > the committer need to know. It would be different for each module (e.g. > AffineTransform is irrelevant to metadata). Here are the links that I regularly send new committers when they are made at the ASF: http://community.apache.org/ http://www.apache.org/dev/new-committers-guide.html http://www.apache.org/dev/pmc.html I think they are worth a ready by all of us in general. HTH explain some things Martin and thanks for the dialogue! Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
