[ka-Map-dev] Road to version 2

[Daniel Morissette]

Lorenzo Becchi wrote:
> 
> 1) maitaining or not retro-compatibility
> My first idea was to create a wrapper inside ka-Map.js to OpenLayers 
> methods.
> Paul suggested to try to think at replacing completely ka-Map object 
> with OpenLoayers map object and then adapt all tools as keymap, legend, 
> scalebar, ecc.
> I actually think that Paul suggestion is the better choice.
> 

I am usually a fan of maintaining backwards compatibility as much as 
possible, but that can sometimes be hard and lead to a bloated system... 
and since bloat is something we cannot afford in the case of JavaScript 
libs, I agree that it may be a better idea to do as Paul suggests in 
this case. The transition to version 2.0 would be a good time to break 
compatibility if that's the best option.

> 
> 2) CVS vs SVN
> this big change will be the good occasion to clean up a little bit the 
> directory structure. CVS doesn't allow to move files and dirs without 
> losing their history.

Is there a proposal on the table for the new directory structure? Will 
ka-Map 1.x be maintained in SVN as well?

Note that I've found out the hard way a few days ago that while SVN 
maintains history on copied files, you cannot simply "svn update" to any 
revision of a file if it has moved.

Note that if we migrate the project from CVS to SVN then I think it is 
critical to maintain all CVS history.


> Paul has asked OSGeo in it would be possible to provide and SVN account, 
> we are waiting for the response.
> this doesn't mean we've already decided to move.
> 

Um, perhaps there was a miscommunication issue, but the wording of the 
request to OSGeo implied that the decision had been made already... or 
at least that's how I and a few others read it.

> 
> 3) BUGZILLA vs TRACK
> some as point 2, Paul asked OSGeo to provide a track account for ka-Map.
> 

The request to OSGeo indicated that maintaining the bug history was not 
critical. I disagree with that: the loss of the bug history (43 open 
bugs and 56 closed ones) should be taken into account in making this 
decision. OSGeo has been testing a tool/script to migrate GDAL's bug 
history to Trac, depending on the amount of work involved then I think 
we should consider the possibility of using that for ka-Map too.

Also, what about the website and mailing lists? Should they move to 
OSGeo as well or are we fine with keeping them on maptools for now?

> 
> 4) OSGeo incubation
> This is not really related to our code but we've started thinking to 
> apply at OSGeo incubation process.
> I've set up a first try of the questionnaire:
> http://wiki.osgeo.org/index.php/Ka-Map_Incubator_Application_Questionnaire
> 

Cool. If that's one of the future goals then should the ka-Map 
development community consider setting up a Project Steering Committee 
(PSC) to lead the future of ka-Map. This will be one of the first 
requirements of OSGeo incubation anyway.

Daniel
-- 
Daniel Morissette
http://www.mapgears.com/