[Incubator] Incubation Progress Page

Cameron Shorter cameron.shorter at gmail.com
Tue Mar 14 14:50:55 EST 2006


In answer to a number of issues on this thread:

At Mapbuilder, we are just finishing up a migration from 
Sourceforge/Drupal to Codehaus in order to use SVN, better bug tracking 
and a different type of wiki.  I'm still unconvinced that changing wiki 
formats was a good idea.
I'm not keen to immediately start another migration as it effects 
productivity on the project, and you loose information in the process.

* I'm concerned about the license of Collabnet and if I were a new 
project joining OSGeo I'd be more concerned.
If my project doesn't make it through the incubator process, or is 
thrown out, then I assume we would need to buy our own copy of 
Collabnet, or go through another costly migration process on the way 
out.  I'd be more comfortable with an Open Source product, or at the 
very least, a long term committment to a "Free for OS projects" license. 
  It is possible this exists, but I couldn't find it in my 3 min look 
over the Collabnet site.

I'd like to see a low impact migration path for all the key tools we use 
and ensure that Collabnet tools are of reasonable quality.
Subversion: Should be no problem

Mailing Lists: I haven't done this, but I suspect we should be able to 
move the archives from Sourceforge to Collabornet?

Issue Tracker:
I wish someone would come up with a standard interface for bug trackers.
I assume that the Collabnet tracker can be tailored so that we can 
remove some of the fields (and make it easier for users)?
We would want to be able to export from JIRA to Collabnet.  JIRA is 
pretty good at exporting, it exports to XML and CSV.  How good is 
Collabnet at importing?
I'm interested to hear what Geotools are doing because they will have 
the same problems.

Wiki:
Again, why isn't there a wiki standard?
I see this as the biggest cost of a migration.  Documentation is large 
and might need to be done by hand.  Does anyone know if there is a tool 
to convert from JIRA wiki format to Collabnet format?

Frank Warmerdam wrote:
> Daniel Brookshier wrote:
> 
>> Sorry, I like to slap my paint with bright colors. It is however a 
>> clear advantage to use a common set of tools.
> 
> 
> Daniel,
> 
> LOL, I like that.  "Slap my paint with bright colors."
> 
> Yes, there are clear advantages to using common tools.
> 
>> This is indeed an issue that we are constantly battling at CollabNet. 
>> Migration is never easy. MapGuide had a similar problem with migrating 
>> their bug database. In the end they are only migrating the open 
>> issues. I wish there was a clean import method, but the CollabNet 
>> platform is not oriented at consuming old information - it is not cost 
>> effective to support all the possible bug trackers and their many 
>> versions.
>>
>> The good news is that the pain of it is fixed. Once you get over the 
>> hump, it is smooth sailing.
> 
> 
> Well, the pain is finite assuming we stay with the collabnet platform in
> the long term.  While that is a desirable outcome, it is not exactly a
> forgone conclusion.  I for one, am leery about making a huge migration
> commitment when I know that next year I might need to migrate back off
> again if the platform contract is not renewed.
> 
>>> PS. I don't see any reason why code would need to be in an OSGeo SVN
>>> tree to be considered valid for our purposes.
>>
>>
>> Agreed, but in what legal context? If the foundation is taking 
>> responsibility it has no weight with a project hosted off site. If it 
>> is on site and their is a legal need to put a project into a private 
>> mode, we have that option. 
> 
> 
> That is an interesting point.  That, for instance if there is a code
> contamination problem we could temporarily close a project if it is on
> the CN platform.  On the other hand, I'm a bit leery about the impact
> on my GDAL clients if someone else can just "close" my repository at
> will.
> 
>  > If it is off site we can not do that. As you say,
> 
>> there is also dilution of brand, but I also argue dilution of resources. 
> 
> 
> Well, the resources wasted are those to maintain the external setups.
> Once setup that is small, and they are already setup.
> 
>> We have to draw the line legally and in some area of status based on 
>> the reach both of the project and the foundation. You have to be 
>> standing completely under the umbrella to be protected from the rain.
> 
>  >
> 
>> Again, more here is better in the long run. Agreed we can't force it. 
>> There are however things to think about. We should promote the 
>> complete absorption path over others and have a few concrete reasons 
>> to do so. The legal implications of a partial move, or even just 
>> simple member project in name only, should be considered.
> 
> 
> Well, we do need to consider this. We certainly need to work out what it
> means for a project to be a "foundation project".
> 
> Best regards,


-- 
Cameron Shorter
http://cameron.shorter.net




More information about the Incubator mailing list