[ka-Map-dev] Road to version 2

[Paul Spencer]

Comments inline

On 23-Mar-07, at 5:12 PM, Daniel Morissette wrote:

> 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.

Agreed.  I thought carefully about this.  Any sort of compatibility  
layer between the existing ka-Map API (such as it is) and OpenLayers  
would introduce additional sources of error, performance issues and  
bloat.  I believe that ka-Map is best served by replacing the core  
API with the OpenLayers API.

>
>> 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?

Good question.  Does anyone have any opinions on whether ka-Map 1.x  
should be in SVN?  Personally I assumed we would bring everything  
from CVS into SVN (including history).

>
> 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.

I don't understand ... can you elaborate?

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

agreed

>
>
>> 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?

Correct, I did say it wasn't important to me :)  I like the idea of  
using Trac because it tightly integrates into SVN.  I don't mind if  
the history bugs are brought over or not.  Unfortunately only hobu  
knows how to do this, and I think he's pretty busy right now.  If  
Shawn could do it, that would be okay, I can abuse him ;)

I don't want to move the web site or the mailing lists because I  
think we get a lot of benefit from being part of the MapTools community.

>
>> 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.

Yes.

>
> Daniel
> -- 
> Daniel Morissette
> http://www.mapgears.com/
> _______________________________________________
> ka-Map-dev mailing list
> ka-Map-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/ka-map-dev

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+