[Incubator] New Application: GeoToolkit

Martin Desruisseaux martin.desruisseaux at geomatys.fr
Tue May 26 13:47:13 EDT 2009

Frank Warmerdam a écrit :

> Part of this is about personalities, part is about approach,
> part is about governance model.  I'm not really sure how to evaluate
> it, though it will be encouraging to see if some decisions get
> made in favor of outside users at the expense of Geomatys priorities.

This is true that we have not yet given any proof that outside users would get 
their concern adressed adequatly. Our strategy is partially based on technical 
tools (DVCS) to workaround a social issue, i.e. give more independance to users 
to workaround the fact that as of today, I'm the only one to have write access 
on the repository hosted on hg.geotoolkit.org. The question of "who decide what 
will be in the release" still a social issue however.

One "way of thinking" that sound strange when we come from a CVS/SVN background 
is that every "commit" on two distincts DVCS can be seen as a fork until someone 
execute the "merge" command. So if two participants have conflicting priorities, 
they can create clones of the repository where each one push their own priority, 
keep merging with the "main" (which repository is "main" is purely a convention) 
repository which would not contain the solution of any participant, until an 
agreement is found, in which case a merge between the two clones is executed and 
that merge pushed to the "main" repository.

However this raise an other concern that OSGeo may need to adress. Given that it 
is so easy to clone a DVCS, put a few (trivial or not) changes in it and release 
that, how a compagny (like Geomatys) which put a huge amount of energy in the 
development of that toolkit can be credited for their work? The thing that can 
scare Geomatys to the point of staying out of OSGeo would be that someone else 
takes Geotoolkit code and push their modified flavor of it as if they were the 
main author (they don't need to said that explicitly - I have meet last automn 
developers of the gvSig project who were convinced that the GeoTools referencing 
module has been wrote by an other compagny), getting contract at the expense of 

>> I'm not sure to understand what "prudent management" means?
> We have obligation with regard to ensuring that contributions are
> properly contributed - for instance by ensuring that all committers
> sign a contribution agreement and are aware of their obligations.

With Adrian around us, if we are drifting on this topic our flaw is likely to be 
pointed out clearly.

> I also expect project to be able to produce blessed releases which
> they believe represent a reasonably solid and vetted level of readiness.

We plan to perform mountly releases, starting at the begining of June. The code 
is actually splitted in two repositories:

   - geotoolkit, which contains code that I ported from GeoTools or elsewhere
     after cleaning. Large part of that code has been running for a while (in
     a different form) in GeoTools.

   - geotoolkit-pending, which contains every else.

My "dictatorial control" applies actually only on "geotoolkit"; I'm not doing 
anything on geotoolkit-pending. As time allow, I pickup "geotoolkit-pending" 
code that I move to "geotoolkit".

> The reason I raise the issue is that I am still unclear on what
> governance model is proposed.  I'm also not so clear what committer
> means in the context of a DVCS or what a "blessed release" means in this
> context.

I have (for now) dictatorial control on the "geotoolkit" repository which is 
hosted on hg.geotoolkit.org web site - only on that repository. I said "for now" 
because I would be happy to leave control to other members, providing I'm 
confident that they have a wide vision of what is in that repository, a good 
understanding of concepts that I consider as mandatory for being allowed to play 
in that repository (e.g. affine transforms and the principles published in 
Josh's book "Effective Java"), they agree with some principles that make 
Geotoolkit distinct to some other projects (e.g. alignment on OGC/ISO standards, 
exactitude of data more important than prety pictures even at the sacrifice of a 
little bit of performance if we can't avoid to). I may wish to wait longer 
before to give write access than what we did in GeoTools.

In case of lack of concensus of a particular topic, we can leave that topic out 
of the "main" repository for now as proposed above and get each party to apply 
their solution on their clone until we merge them. But of course I have no 
experience of such process yet.

Which DVCS would be used for the release still an open question. A conservative 
answer would be the "less common dominator", e.g. the "main" repository above 
where we have leaved out the controversed topics for the time being.


More information about the Incubator mailing list