[Geoserver-devel] GeoServer commit access for Rini Angreani

GeoServer GeoServer Developer
1

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.

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

2

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

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

3

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.

4

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 <jdeolive@anonymised.com> 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

5

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.

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.

There is a bit of a chicken-and-egg problem here. If new developers are working offline and submitting patches through an intermediary or module despot, you will not hear from them on the list, because they will be justifying their patches to the intermediary, not the community. So how do they get known until they get a chance to work in the open? In the same way that modules are broken into a hierarchy, it would be nice if commit access could be as well, but this not supported by subversion at this time. This is an issue of scalability; as the community grows, it will be harder for all active developers to know all other active developers.

For effective development, developers need write access to a repository so their work is covered by continuous integration. In my view, as long as a developer subscribes to the mailing lists and behaves themselves, they should be given the benefit of the doubt. As long as communication is good within a module, and externally-visible changes are communicated to the community, I believe this approach will work.

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

6

Hi Andrea,

I have signed the contributor agreement and sent it with my employer's disclaimer today.
I have just started working with Ben on GeoServer community/app-schema module and would appreciate commit access to this module.
Ben would review my changes before committing to SVN, and I will be more active with the mailing list as I progress with my work.

Cheers

Rini

-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com]
Sent: Monday, 9 February 2009 4:56 PM
To: Caradoc-Davies, Ben (E&M, Kensington)
Cc: Geoserver-devel; Angreani, Rini (E&M, Kensington)
Subject: Re: [Geoserver-devel] GeoServer commit access for Rini Angreani

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

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

7

There is a bit of a chicken-and-egg problem here. If new developers are working offline and submitting patches through an intermediary or module despot, you will not hear from them on the list, because they will be justifying their patches to the intermediary, not the community. So how do they get known until they get a chance to work in the open? In the same way that modules are broken into a hierarchy, it would be nice if commit access could be as well, but this not supported by subversion at this time. This is an issue of scalability; as the community grows, it will be harder for all active developers to know all other active developers.

For effective development, developers need write access to a repository so their work is covered by continuous integration. In my view, as long as a developer subscribes to the mailing lists and behaves themselves, they should be given the benefit of the doubt. As long as communication is good within a module, and externally-visible changes are communicated to the community, I believe this approach will work.

Sure, but the first step is communication, not requesting commit access. We hand out commit access quite easily to community modules. All a developer has to do is show up on the list, explain what they want to do, and then request a new module.

Mentors that are working with a team of developers who are new to the project should imho encourage the developers into this process, not hide them from it. Jody can speak more to this as he has experience doing this. And indeed when a new employee joins opengeo they are not automatically given commit rights, they have to present themselves and their intentions to the community first.

2c.

Kind regards,

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

8

Ben Caradoc-Davies wrote:

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.

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.

There is a bit of a chicken-and-egg problem here. If new developers are working offline and submitting patches through an intermediary or module despot, you will not hear from them on the list, because they will be justifying their patches to the intermediary, not the community.

They should address the community directly and propose patches to the
community. No need to be shy.

So how do they get known until they get a chance to work in the open? In the same way that modules are broken into a hierarchy, it would be nice if commit access could be as well, but this not supported by subversion at this time. This is an issue of scalability; as the community grows, it will be harder for all active developers to know all other active developers.

I have a hard time believing GeoServer will ever have more than 10-20
active committers at a given time, but I'll be gladly proven wrong on
this one. :wink:

For effective development, developers need write access to a repository so their work is covered by continuous integration. In my view, as long as a developer subscribes to the mailing lists and behaves themselves, they should be given the benefit of the doubt. As long as communication is good within a module, and externally-visible changes are communicated to the community, I believe this approach will work.

I don't like this approach, but anyways, just so that nobody thinks I
may want to derail the complex features effort here is my +1 for letting
Rini have commit access. Afaik this is all you need. Now Rini needs to
get a xircles.codehaus.org login, apply for GeoServer dev access, and
tell us when she did so, so that we can approve her access to svn.

Cheers
Andrea

9

Rini.Angreani@anonymised.com wrote:

Hi Andrea,

I have signed the contributor agreement and sent it with my employer's disclaimer today.
I have just started working with Ben on GeoServer community/app-schema module and would appreciate commit access to this module. Ben would review my changes before committing to SVN, and I will be more active with the mailing list as I progress with my work.

Nice to hear from you Rini :slight_smile:
I guess Ben can show you the way to get a xircles.codehaus.org login and to apply to become a geoserver developer there.
Let me know when that is done

Cheers
Andrea

10

Rini.Angreani@anonymised.com ha scritto:

Hi Andrea,

I finally managed to get a xircles login and applied to become a geoserver developer.
Sorry for the delay. Please approve my application so I can contribute.

Hi Rini,
I've given you commit access. Please understand that changes to the core
of GeoServer should go through the review of a core developer anyways (open a bug/improvement report at jira.codehaus.org, attach a patch).

Also review the whole discussion we had in this thread about trust
between developers:
http://www.mail-archive.com/geoserver-devel@lists.sourceforge.net/msg03507.html

And finally, thanks a ton for getting on board and helping us
improve GeoServer :slight_smile:

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

11

Welcome aboard Rini, and congrats for the excellent job on feature chaining, I'm impressed by it.

Gabriel
Andrea Aime wrote:

Rini.Angreani@anonymised.com ha scritto:

Hi Andrea,

I finally managed to get a xircles login and applied to become a geoserver developer.
Sorry for the delay. Please approve my application so I can contribute.

Hi Rini,
I've given you commit access. Please understand that changes to the core
of GeoServer should go through the review of a core developer anyways (open a bug/improvement report at jira.codehaus.org, attach a patch).

Also review the whole discussion we had in this thread about trust
between developers:
http://www.mail-archive.com/geoserver-devel@lists.sourceforge.net/msg03507.html

And finally, thanks a ton for getting on board and helping us
improve GeoServer :slight_smile:

Cheers
Andrea

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.