[Incubator] New Application: GeoToolkit
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
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