2)
Working branches will be created in the uDig and Geotools repositories for
my team and myself to do the required modifications, merging changes from
the trunk as often as possible. If and when our branches have stabilized and
the communities have verified that the results are useful and correct, the
working branches can be merged into the trunk and die.
We would like to meet the members of your team; do they have commit
access at this time etc?
There's three of us in my team, and so far I'm the
only one working with uDig. When I've tidied up what I've done so far on our
own plugin and when we've found a way of managing all the repository access
and branching issues, I'm planning to let someone else take over, but probably
not before the new year, seeing that our uDig plugin is just a small
subproject of our regular work and not a top priority
one...
So
far, I don't have commit access for uDig, and it would be helpful if you
can set up an account for me, to get a chance of pushing some trunk-compatible
changes back - if you prefer a pull model, that's fine with me also.
Considering Adrian's feedback from the Geotools perspective and the fact that
they have started using Mercurial anyway, I really think it would be the best
thing for us to work on Mercurial clones both of uDig and
Geotools, until we've reached a stabilized subset of uDig
and Geotools without our dear friend net.refractions.udig.libs. Until
that point, it wouldn't really make sense to merge any changes back into the
uDig repository, unless you would like to mirror our Mercurial work on a
Subversion branch.
What
about uDig wiki access and editing policies? I think it would be useful if I
could document our plan and our progress there. Even if the software changes
happen on a repository clone, at least the documentation should be kept in one
place.
We may be able to set up HTTPS for this stuff (we would need to talk to
admin@xxxxxxxxxxxxxxx for
details).
That would definitely make things easier. On the other hand, if we do
work with Mercurial, then it's not that urgent - I could pull the changes from
Subversion to Mercurial at home and push them to the team repository at work.
One of the nice features of DVCS :-) On the other hand, I think it would
be rather hard to push anything from Mercurial back into
Subversion.
Then
the Geotools libraries will be osgified as outlined in
http://docs.codehaus.org/display/GEOTDOC/03+GeoTools+and+Eclipse+or+OSGi,
without breaking the META-INF/services mechanism and without losing the
capability of being used as plain old JARs on the classpath.
This is the part that is of interest to me; you may wish to show up for a
geotools IRC meeting and talk to the community about it.
Sure
why not - when is the next one? If it's during office hours (GMT+1), I'll
probably unable to access IRC, again thanks to our firewall and web proxy. I'd
have to find an IRC-over-HTTP service and hope that the HTTP server is
not on the blacklist of our proxy...
Harald
