Again, we have a little bit of a corner case perhaps, with commit access to someone who works as part of a team, but isnt the primary point of contact with the community.
I know its a lot easier to interact within a team through a software development process that uses a commit/review cycle than reconciling off-line patches with a code-base that may have changed, but maybe thats an overhead we should live with. If we had module-level commit rights, it would be simple - the module maintainer would take the burden of choosing who and how. I fully sympathise with the views of the community here - the pattern that we use seems to be a "vouched for and limited by intent to specific modules" pattern, so I'd vote +1 on this basis. If Rob A On Tue, Feb 10, 2009 at 2:25 AM, Justin Deoliveira <jdeol...@opengeo.org> wrote: > Hi Ben, > > Just to second what Andrea already stated. I am ok with granting commit > access in this case since you are vouching, but as Andrea said we are > generally not in the practice of handing out commit access without > interaction on the developers list first. And (of course) this would be > limited to just the specific community module (which it sounds like it > would be). > > -Justin > > Andrea Aime wrote: >> Ben Caradoc-Davies ha scritto: >>> I am pleased to nominate my colleague Rini Angreani for commit access to >>> the GeoServer subversion repository. >>> >>> Today I committed to the GeoTools repository her implementation of >>> app-schema feature chaining, which enables support for multiple >>> multi-valued properties and properties from different sources. Rini will >>> be making further improvements to the app-schema implementation (in >>> GeoTools modules/unsupported/app-schema), and will need to extend and >>> maintain integration tests in GeoServer community/app-schema; this work >>> will be facilitated by her having commit access to the GeoServer repository. >> >> Hi Ben, >> nice to hear you've someone helping you out with the work. >> >> The first thing that comes to mind is that Rini needs to sign and send a >> GeoServer contributor agreement or working for an organisation that >> already signed the contributor agreement). >> >> The second one is that it feels a bit un-natural to grant commit access >> to someone that never even wrote a mail to geoserver-devel. >> In open source the committer access is given on a mutual trust basis, >> each developer being evaluated as an individual and not by the >> company that employs her. >> >> The fact that you know her personally and that you trust her enough >> to nominate her for commit access (basically taking the responsibility >> of the evaluation completely on your shoulders) speaks well for her, >> and I can be persuaded to just say that it's ok to give her commit >> access to selected modules. I just hope she understands becoming part >> of an open source community is more than just having a commit >> access, but it's also about showing yourself directly on the ml >> and irc channel, communicate with the other developers about what >> you're doing and so on. An open source project is a network of >> people, not just a shared technical infrastructure, if you get >> what I mean. >> >> Cheers >> Andrea >> > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
