First of all i want to thank everyone here for the open communication;
seriously that is one of our communities strengths and is something to be
encouraged. I would much rather have our discussion in public where we can
do something about them that have people be unhappy and quiet and drop out
as (a popular alternative).
RELATIONSHIP WITH MODULE MAINTAINERS AND PSC
The division of responsibility / work between these two rolls is a bit
stressed. In general we are leaning too much on the PSC as a group of
volunteers (since demonstrating responsibility for the library is the
pre-req for joining the PSC by definition is prone to bouts of selfless
fixing above and beyond the call of duty). We need to remember that
responsibility lies with the module maintainer.
We have had a couple talks about breaking the library down and building it
up again in terms of what we actually use; I urge us to take on this work at
the module maintainer level - taking responsibility as we go to bother merge
and/or split modules into sensibible maintabable groups.
RELATIONSHIP WITH GEOTIDY
I have struggled with what GeoTidy is doing as a community leader - and
decided I cannot really have a useful opinion. It is a separate undertaking
not beholden to community direction.
I am excited that it has motivated Martin into fixing some long standing
issues (and seriously it is good to here Martin being happy about the work
he is doing; he has sounded stressed for far too long). As for the
relationship with GeoTools everything is really clear cut for me; Martin is
using it as a venue to do a pretty major code cleanup and has offered to
backport some of the work to the metadata and referencing modules; that is
within his responsibility as module maintainer and if this is a way for him
to work quickly it sounds like a great deal all around.
The only part where I am concerned is with the user community getting
confused; we need to be clear with the providence of what is published to
the maven repositories.
In short: Lean on module maintainer roll; and look forward to a code update;
view as a test case of distributed version control.
RELATIONSHIP WITH DISTRIBUTED VERSION CONTROL
I can have an opionon on GeoTools; and if this use of mecurial is helping
Martin then so much the better. The only issues i see are:
- with respect to Jira. Perhpas Martin can "resolve" issues when he has
addressed them in his branch; and close them with the fix has been applied
to trunk. Or we may need to set up a seperate "tag" in Jira and treat each
distribution point like a branch
- I just do not want to get in the situtation where I am invited to check
out the mecurial branch and hunt down this diffs myself. My understand is
that having a ceneral server which releases are made from is a common
practice in the distributed coding world; I want to keep these ideas going
forward. (I can understand if there is a rush; but I want to keep respecting
the module maintainer relationship and not lean too much on the PSC).
In general I am sad when developers end up scattered across branches (it
makes it much harder for the user community to hold us accountable). We have
had it happen a couple of times in our project life.
We do know how to play carefully and well with each other on this stuff.
Distributed version control is here to stay; and we would do better to
define polices than watch from the sidelines. In the past project teams have
grabbed a copy of GeoTools and started hacking (we have seen this happen
around 5 times now); if we define distributed version control policies with
this in mind it will help. Think of this as similar to how we defined
unsupported modules in order to make publick work that was otherwise lost as
commercial or student projects ended?
RELATIONSHIP WITH UNSUPPORTED MODULES
Our experiement is being successful; one recent example is the SoC
FeatureCache work - Emily was able to fix it up and apply it to some uDig
development work. In the past a student would of done this work and it would
of been forgotten about.
The experiment also has dangers; modules that stay unsupported longer then
required. The jdbc-ng work has been going on for a while; and does not have
a roadmap for intergration yet. This is an area where the PSC can help with
planning (ie stratigic direction). Still we have witnessed a couple of
modules make the transition lately - but it is something to keep an eye on.
RELATIONSHIP WITH GEOAPI
This one is under strain - mostly due to lack of
participation/accountability. On the bight side GeoAPI is kicking back up as
an OGC project. Something else to keep an eye on.
Remember that GeoAPI is a marketting / documentation tool for us as a
project. Participation costs us some time and effort but has also offered us
some rewards (and improved interfaces) in the past.
RELATIONSHIP WITH OSGEO
This one is looking up; we have migrated to OSGeo hardware; and we can
migrate the mailing lists as well if needed? The foundation was helpful in
settling our legal and header issues.
There are areas for improvement; in particular on the branding side of
things (although to be fair any change would require some strict changes on
our side as well).
THANKS
Thanks for your kind words Simone; I am afraid I was sick last week and left
you stranded for some presentation materials.
Jody
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
