Hello Jody
>
> Thanks a lot for your email. There is a lot of content to think about.
No hurry; I have taken my time to write a useful email after all.
> I can not really make a useful answer right now, since I still working on
> the referencing module. However there is a link I could submit:
>
> Jody Garnett a écrit :
>
>> - 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
>>
>
> The approach that I applied was to create a new JIRA task, "Consider
> leveraging geotidy in geotools". The issues that I fixed are still open on
> the GeoTools JIRA, but are linked to the above-cited task with a "depends
> on" link. So if you look at the task below:
>
> http://jira.codehaus.org/browse/GEOT-2117
>
> the "This issue is depended upon by" column gives you the issues fixed in
> geotidy.
Thanks that is a useful link; I am not sure that process will scale (but you
will have to let me know how the process is working for you). Are you able
to keep track of the version information you need - using say comments or
something? I would like to plan for a situation where mecurial or bzr is in
wider use and set up polices that can see us through such a shift.
We had similar policy discussions when with the migration to svn; and were
still startled when it enabled groups to work on branches for months at a
time (something that was not always possible with CVS).
- 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;
>
In my understanding this is the way Sun works with OpenSolaris; developpers
> are on Mercurial but Sun uses Subversion for centralizing the code to be
> released. Other projects like OpenJDK are on Mercurial only, but I guess
> there is no clear rule and the decision to use a centralized repository (in
> addition of the distributed one) depends on each community...
You are correct there are two ways to use distributed version control (based
mostly on release policy as I understand it):
- a single central repo - that is only central in the fact it is the one
used to make the official releases out of
- no center; releases are made and branded by anyone with the time to make
them
Given our use of maven repositories I am advocating the first approach; with
the osgeo repository used as the location to generate and release official
geotools artifacts from.
Aside: I have yet to really here of a bug tracker that has responded to the
distributed version control senario; I wonder if my idea of treating
locations like branches will work?
Cheers and happy hacking,
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
