I understand that we have a Bluenet branch of Geonetwork.
There are some good reasons for maintaining multiple branches, but it comes with a significant maintenance cost.
I'm wondering what the reasons are for maintaining the Bluenet MEST branch separately to the trunk and whether it would be possible to merge these branches together, possibly by tweaking our software development processes.
Eg, if we have a separate branch for stability reasons, maybe we have a business case to spend effort on automated testing procedures.
--
Cameron Shorter
Geospatial Systems Architect
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254
Think Globally, Fix Locally
Commercial Support for Geospatial Open Source Solutions
http://www.lisasoft.com/LISAsoft/SupportedProducts.html
Cameron Shorter wrote:
I understand that we have a Bluenet branch of Geonetwork.
There are some good reasons for maintaining multiple branches, but it comes with a significant maintenance cost.
I'm wondering what the reasons are for maintaining the Bluenet MEST branch separately to the trunk and whether it would be possible to merge these branches together, possibly by tweaking our software development processes.
Eg, if we have a separate branch for stability reasons, maybe we have a business case to spend effort on automated testing procedures.
Apart from historical reasons (see earlier posts) and the normal process of developing and testing in your own branch, there is no agreed method for supporting profiles of standards (as opposed to different standards) in GN, and in BlueNet there isn't a clean separation (yet) between the code and facilities that support profiles and the rest of GeoNetwork.
In the short term I think this could be addressed by:
1. Getting the existing methods for supporting profiles of standards (as used in BlueNet and possibly for the Inspire work - Francois?) - merged, approved by the PSC and into the GeoNetwork trunk.
2. Consolidating as much as possible profile specific information in the appropriate profile directory eg. web/geonetwork/xml/schemas/iso19139.mcp - this includes presentation and conversion xsls and various other things (like templates and sample data) that are still spread around the install directory :-).
3. Bundle up national profiles as optional installation packages (to be supplied with the GN release?) - responsibility for the installation packages to be handed to maintainer(s).
In the long term, an architecture that would allow dynamic plugin of a profile would be good but for the moment I think the above would go some way to allowing more people to contribute to the development process on trunk. If the fact that the national profile is on a branch is an impediment to GeoNetwork continuing as the Australian Government Metadata Entry Tool (OSDM) and the ANZLIC Metadata Entry Tool (ANZLIC metadata project), then this should help.
The rest of the perception about the BlueNet branch is (to me) the usual tension that happens when development gets a bit far away from the trunk and needs to be sync'd.
Cheers,
Simon