[GeoNetwork-devel] [Aust-NZ] Merging new developments into core (was: Finding a way forward)

[Simon Pigot]

Roald de Wit wrote:
> Hi Jeroen et al,
>
> Jeroen Ticheler wrote:
>   
>> At this point I want to have some discussion on the GeoNetwork 
>> developer list to find a good working solution. The most obvious one 
>> for me is to have sandboxes set up for those that develop new 
>> functions. This will allow a developer to just do his work as normal, 
>> but has the big advantage that others can see what's happening and can 
>> be informed on forehand. So when time comes to merge new code to 
>> trunk, we already had a chance to see the code (through commit mailing 
>> list for instance) and the process of a proposal and voting would be 
>> slimmed down a lot.
>> Looking forward to some good discussion on this.
>>     
>
> The process you are describing above looks very similar to what happens 
> in OpenLayers (not sure if you had this project in mind when writing).
>
> IMO, having sandboxes is a good thing. Besides what you mention above, 
> it makes it easier to collaborate, stay up-to-date with and create 
> patches against the trunk. OpenLayers has recently started having an 
> add-in system for useful contributions that don't belong to the core 
> application. A similar approach could work well with GeoNetwork too, I 
> assume.
>
> If there is approval from the GeoNetwork PSC, how soon could we see 
> (amongst others) the BlueNet branch in the GeoNetwork SVN repository 
> (maybe as a sandbox to start with)? How does the BlueNet team feel about 
> this possible move? Does this sound like the 'wheels' that CSIRO could 
> help out greasing (if resources are a problem)?
>   
We've always wanted to hold the BlueNet branch in the geonetwork svn but 
have been a bit hesitant to add to the admin load of the geonetwork svn 
admins*.

I don't see any delay in doing this - especially as I'd already offered 
the code in response to the original collaboration proposal by Cameron - 
its always been possible the problem has been finding a nice way to do it.

Naturally I'd need to refresh BlueNet management on this but its 
something we've often spoken of as a preferred option.

Cheers,
Simon

* - Instead we'd been looking at setting up access to an svn at bluenet 
- using svk to mirror the trunk and having the bluenet code as a branch. 
This seemed to work fine in testing as long as the trunk and the branch 
don't get too far out of sync - but we've never made the svn (used by 
svk) available - other priorities and concern about competing/confusing 
svns has meant that it didn't happen. Sounds like this idea can quietly 
drop off the twig....:-)