Hi Simon and others,
I’m reading through the interesting archived discussions you have on the aus-nz list (only just subscribed).
> Up until last month we've fed a lot of the code from the MEST back into
> the trunk but there is a need to write proposals and get them approved
> by the community before some of the later changes can be committed.
> Community approval is a good thing but it takes time to get this
> together and slot things in to the trunk - that time lag would be a
> problem for anyone (not just BlueNet) - especially when the priority for
> us has been features we need.
I'm getting quite concerned when I read this, as I feel that putting such procedures in place should have minimum effect on the normal development process. What it should do is start some discussion where needed and help to ensure that not just anything will get into core. Proposals do not have to be endlessly long either.
We need to find a good way of dealing with this, since delaying to add new developments to core may in the end be the cause of a fork if your developments deviated to much from trunk. Add to that the fact that you have moved on to new stuff, it becomes even more likely we'll never see the change merged back. :-(
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.
Ciao,
Jeroen
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)?
Cheers,
Roald de Wit
Software Engineer
roald.dewit@anonymised.com
Commercial Support for Open Source GIS Software
http://lisasoft.com/LISAsoft/SupportedProducts/
Hi Roald,
On May 20, 2008, at 2:21 PM, 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).
Oh, didn't know about that! Good to know.
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.
Yes, can well imagine such thing. This is particularly true for things like language modules, application profiles and custom 'skins' but also for custom editor interfaces or add-ons like the metadata extraction tools.
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)?
For what the PSC approval concerns, I can second or make a proposal with input from others. That shouldn't be a long process though.
Cheers,
Jeroen
Cheers,
Roald de Wit
Software Engineer
roald.dewit@anonymised.com
Commercial Support for Open Source GIS Software
http://lisasoft.com/LISAsoft/SupportedProducts/
Jeroen Ticheler wrote:
Hi Simon and others,
I'm reading through the interesting archived discussions you have on the aus-nz list (only just subscribed).
Up until last month we've fed a lot of the code from the MEST back into the trunk but there is a need to write proposals and get them approved by the community before some of the later changes can be committed. Community approval is a good thing but it takes time to get this together and slot things in to the trunk - that time lag would be a problem for anyone (not just BlueNet) - especially when the priority for us has been features we need.
>
> I'm getting quite concerned when I read this, as I feel that putting such procedures in place should have minimum effect on the normal development process.
> What it should do is start some discussion where needed and help to ensure that not just anything will get into core. Proposals do not have to be endlessly long
> either.
> We need to find a good way of dealing with this, since delaying to add new developments to core may in the end be the cause of a fork if your developments
> deviated to much from trunk. Add to that the fact that you have moved on to new stuff, it becomes even more likely we'll never see the change merged back.
> 
They will - we've just been busy since the 2.2 release working on features/fixes for BlueNet workshops :-). As a protection against not merging changes back I've made myself post messages to the developers group giving an overview of what we've been doing at various times. Those emails were/are placeholders for future proposals.
I think the point of the previous messages in these exchanges (leaving aside the mildly annoying statements like lack of progress :-)) has been about forging a more effective community to drive GeoNetwork development - a first step for that in AU/NZ is to make the BlueNet MEST (with its embedded AU/NZ specific profiles) available via an svn which leads to....
> 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.
>
.....your suggestion of sandboxes as one way of dealing with this - its a good idea and I've replied to that in a later email on this in which Roald gave some details about sandboxes elsewhere and asked specific questions about BlueNet.
Cheers,
Simon
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....
Hi Simon,
Thanks! I was absolutely confident in you committing those changes at some point. It seems we can now try to facilitate the process quickly. I will make the proposal for a sandbox environment now.
Cheers,
Jeroen
On May 20, 2008, at 3:52 PM, Simon Pigot wrote:
Jeroen Ticheler wrote:
Hi Simon and others,
I'm reading through the interesting archived discussions you have on the aus-nz list (only just subscribed).
Up until last month we've fed a lot of the code from the MEST back into the trunk but there is a need to write proposals and get them approved by the community before some of the later changes can be committed. Community approval is a good thing but it takes time to get this together and slot things in to the trunk - that time lag would be a problem for anyone (not just BlueNet) - especially when the priority for us has been features we need.
>
> I'm getting quite concerned when I read this, as I feel that putting such procedures in place should have minimum effect on the normal development process.
> What it should do is start some discussion where needed and help to ensure that not just anything will get into core. Proposals do not have to be endlessly long
> either.
> We need to find a good way of dealing with this, since delaying to add new developments to core may in the end be the cause of a fork if your developments
> deviated to much from trunk. Add to that the fact that you have moved on to new stuff, it becomes even more likely we'll never see the change merged back.
> 
They will - we've just been busy since the 2.2 release working on features/fixes for BlueNet workshops :-). As a protection against not merging changes back I've made myself post messages to the developers group giving an overview of what we've been doing at various times. Those emails were/are placeholders for future proposals.
I think the point of the previous messages in these exchanges (leaving aside the mildly annoying statements like lack of progress :-)) has been about forging a more effective community to drive GeoNetwork development - a first step for that in AU/NZ is to make the BlueNet MEST (with its embedded AU/NZ specific profiles) available via an svn which leads to....
> 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.
>
.....your suggestion of sandboxes as one way of dealing with this - its a good idea and I've replied to that in a later email on this in which Roald gave some details about sandboxes elsewhere and asked specific questions about BlueNet.
Cheers,
Simon