|Version 6 (modified by 11 years ago) ( diff ),|
TinyOWS and Mod-Geocache integration in the MapServer project
This page discusses the administrative details of the integration of the TinyOWS and mod-Geocache projects into the MapServer project, if RFC 70 and 71 are accepted.
- It is planned that the MapServer PSC would become the ultimate authority for the merged projects
- Olivier Courtin to be added to the MapServer PSC as owner of the TinyOWS module
- Thomas Bonfort is already on the PSC and will act as owner of the mod-Geocache module
- It is understood that even though the ultimate decision authority is the PSC and the merged projects will have to follow the PSC rules (RFCs, etc.), the recommendations of a module owner are most of the time followed and the PSC does not get in the way of a module owner trying to make enhancements to the software, unless other devs envision possible issues, in which case the group works together to define a better solution. (in other words, Oliver and Thomas will remain the technical leads of their respective modules and the PSC will do its best to support them in their work)
- How do we refer to the two sub-projects once merged? Do we call them sub-projects? Modules? Components?
- If we want the whole thing to be promoted as a "MapServer Suite" (or stack, or ....) then we need clear names for each component
- MapServer core needs a name (or do we just call it "MapServer core" ... or CGI?)
- RFC 70 says nothing about the preferred name for TinyOWS after the merge
- RFC 71: “Mod-Geocache” as a name is a poor choice, and should be changed during the integration with MapServer. The author has no predefined idea as to what the solution should be named, ideas will be greatly appreciated.
- MIT in all cases:
Release planning / scheduling
- Tricky: we want to allow TinyOWS and Mod-Geocache to have an independent and faster release cycle than MapServer core which is more mature. But one of the drivers for this merge is that users would also benefit from a combined/unified release of the full suite every once in a while... so we need to be able to allow a mix of both.
- Release numbering?
- MapServer 6.x, TinyOWS 1.x, Mod-Geocache 0.4 ... confusing if we want to appear as a unified project... and then which version number do we give to the complete suite when we release as a whole?
- Maybe adopt a common release numbering scheme? e.g. Ubuntu-style based on year.month? Would allow intermediate releases by component, while having consistent release numbers between all components over time... e.g. MapServer suite with all components initially released as 11.08 (august 2011), next major release of MapServer core planned for early 2012, but in the meantime sub-projects can be released as 11.10, 11.11, etc... and next full suite release (including MapServer core) could be around February as v12.2? This also allows for bugfix releases as 11.8.1, 11.8.2, etc.
- Other options?
Build system integration
- Single build system or multiple/separate ones? It seems that we need a mix of both...
- Linux: uses autoconf + Makefiles in all cases ... a merge, or at least some sharing is feasible
- What about Windows?
Source and binary packaging
- Individual packages as follows?
- What about the combined suite? Do we ever want to distribute it as a single source package or not?
- Any naming or other packaging recommendations for binary packagers?
- All projects to use the existing mapserver lists?
- RFC 70 says: tinyows-dev and tinyows-users should be stopped and news discussions should occurs to relevant mapserver ones.
- RFC 71 has nothing explicit but mentions the switch to mapserver-dev (which would imply mapserver-users as well)
- MapServer currently uses:
http://svn.osgeo.org/mapserver/trunk/mapserver/ http://svn.osgeo.org/mapserver/trunk/msautotest/ http://svn.osgeo.org/mapserver/trunk/docs/ ... http://svn.osgeo.org/mapserver/branches/branch-6-0/mapserver/ http://svn.osgeo.org/mapserver/branches/branch-6-0/msautotest/ http://svn.osgeo.org/mapserver/branches/branch-6-0/docs/ ... http://svn.osgeo.org/mapserver/tags/rel-6-0-1/mapserver/ http://svn.osgeo.org/mapserver/tags/rel-6-0-1/msautotest/ (no tagging for docs)
- RFC 70 suggests, for TinyOWS:
svn.osgeo.org/mapserver/trunk/tinyows svn.osgeo.org/mapserver/branches/tinyows-1.0 svn.osgeo.org/mapserver/tags/tinyows-1.0.0
- RFC 71 suggests, for mod_geocache:
svn.osgeo.org/trunk/mapserver/mod-geocachewhich should probably be:
svn.osgeo.org/mapserver/trunk/mod-geocache svn.osgeo.org/mapserver/branches/mod-geocache-0.4 svn.osgeo.org/mapserver/tags/mod-geocache-0.4.0
- If we adopt the above then how do we deal with branching and tagging for the combined MapServer suite?
- We currently have msautotest
- I almost wish we moved msautotest into the mapserver directory and distributed it that way. That would allow for separate test suites. I tend to install it that way. (sdlime)
- Do we want combined or separate test suites?
- All projects to use the same http://trac.osgeo.org/mapserver/
- RFC 70: TinyOWS use a Trac, but as only few tickets are still open, an efficient way is just to create them back in MapServer one. Should imply a new component in MapServer Trac, called: TinyOWS.
- RFC 71: There are currently no open bugs to transition to the MapServer trac. The open feature enhancements will be manually migrated to the MapServer trac instance.
All projects to use http://trac.osgeo.org/mapserver/ ?
Website and documentation
- How do we organize docs and the website in the context of combined projects?
- How do we deal with releases (and docs updates) that are not synchronized?
- All projects to adopt the same Sphinx/RST tools as current MapServer docs
- RFC 70 says: Move TinyOWS trac Wiki documentation to RST syntax. [...] tinyows.org domain could be redirected to the coming MapServer TinyOWS documentation pages.
- RFC 71 says: The mod-geocache documentation is rather sparse, and consists essentially of a commented configuration file. There will have to be an effort to add documentation to the main mapserver doc site, and to migrate the few wiki pages from the google-code hosting.