Hi PSC,
This is a motion for you to discuss and vote on related to a discussing on the list that clearly points to the need of a sandbox environment in SubVersion.
Justification:
Allow developers to use the GeoNetwork SVN as a place to store their new software developments within the sandbox.
This will help to keep projects aligned with the code on trunk and will also help to quickly merge new functions into trunk. By developing in a sandbox, other developers have an early chance to see what is been developed in the sandbox. This will make it easier to make, understand and discuss proposals for new functionality and will help to avoid forking.
How:
- We'll create a sandbox directory on SVN and add working copies of the trunk in there for those who want to work on a sandbox.
- Sandboxes should have a limited lifetime and be focussed on development of new functionality that is intended to be merged back into trunk when accepted by the PSC.
- New committers will be added to SVN in the understanding that they only work on the sandbox.
- Commit access to trunk is not given to them, unless they become approved committers to the trunk or have received the OK for an individual commit.
So I need one of you to second the motion and the others to vote.
Ciao,
Jeroen
+1 
On May 20, 2008, at 5:40 PM, Simon Pigot wrote:
Jeroen Ticheler wrote:
Hi PSC,
This is a motion for you to discuss and vote on related to a discussing on the list that clearly points to the need of a sandbox environment in SubVersion.
Justification:
Allow developers to use the GeoNetwork SVN as a place to store their new software developments within the sandbox.
This will help to keep projects aligned with the code on trunk and will also help to quickly merge new functions into trunk. By developing in a sandbox, other developers have an early chance to see what is been developed in the sandbox. This will make it easier to make, understand and discuss proposals for new functionality and will help to avoid forking.
How:
- We'll create a sandbox directory on SVN and add working copies of the trunk in there for those who want to work on a sandbox.
- Sandboxes should have a limited lifetime and be focussed on development of new functionality that is intended to be merged back into trunk when accepted by the PSC.
- New committers will be added to SVN in the understanding that they only work on the sandbox.
- Commit access to trunk is not given to them, unless they become approved committers to the trunk or have received the OK for an individual commit.
So I need one of you to second the motion and the others to vote.
I'll second the proposal - it looks a lot better than I expected in terms of admin!
Cheers,
Simon
A few comments on admin, based on watching how the Openlayers sandbox has developed:
Jeroen Ticheler wrote:
Hi PSC,
This is a motion for you to discuss and vote on related to a discussing on the list that clearly points to the need of a sandbox environment in SubVersion.
+1, although I realise I'm not on the PSC.
Justification:
Allow developers to use the GeoNetwork SVN as a place to store their new software developments within the sandbox.
This will help to keep projects aligned with the code on trunk and will also help to quickly merge new functions into trunk. By developing in a sandbox, other developers have an early chance to see what is been developed in the sandbox. This will make it easier to make, understand and discuss proposals for new functionality and will help to avoid forking.
How:
- We'll create a sandbox directory on SVN and add working copies of the trunk in there for those who want to work on a sandbox.
Developers should be able to create their own sandboxes. Eg:
sandbox/ticheler/geonetwork/...
or
sandbox/bluenet/geonetwork/...
- Sandboxes should have a limited lifetime and be focussed on development of new functionality that is intended to be merged back into trunk when accepted by the PSC.
-1
If a developer provides software worthy of the trunk, then yes, it can be removed from the sandbox.
However, in Openlayers people have created experiemental branches, or project specific branches which have not made it back too the trunk and probably never will. However it is nice to keep them as reference for future.
- New committers will be added to SVN in the understanding that they only work on the sandbox.
- Commit access to trunk is not given to them, unless they become approved committers to the trunk or have received the OK for an individual commit.
So I need one of you to second the motion and the others to vote.
Ciao,
Jeroen
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
--
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
Hi Cameron,
On May 20, 2008, at 10:17 PM, Cameron Shorter wrote:
A few comments on admin, based on watching how the Openlayers sandbox
has developed:
How:
- We'll create a sandbox directory on SVN and add working copies of
the trunk in there for those who want to work on a sandbox.
Developers should be able to create their own sandboxes. Eg:
sandbox/ticheler/geonetwork/...
or
sandbox/bluenet/geonetwork/...
Yes! The only problem is that someone needs to give them access to SVN in the first place It is indeed a good idea to use names as the first level subdir under sandbox!
- Sandboxes should have a limited lifetime and be focussed on
development of new functionality that is intended to be merged back
into trunk when accepted by the PSC.
-1
If a developer provides software worthy of the trunk, then yes, it can
be removed from the sandbox.
However, in Openlayers people have created experiemental branches, or
project specific branches which have not made it back too the trunk and
probably never will. However it is nice to keep them as reference for
future.
OK, I have no problem with keeping them. At the same time I feel that they should in principle be created with the idea to become inactive after a while once the useful stuff has been merged.
Ciao,
Jeroen
+1
I don't much care either way whether the sandbox areas are kept permanently or not, so it doesn't affect my vote one way or another. Keeping them around too long makes the merge process much harder, but that's a problem for the sandbox owner, isn't it? I do my own development (such as it is) locally here anyway, and only update from the main branch into my local version until I've finished my changes, then merge them all at once. Having a sandbox to work from solves some of my concerns about playing with new things on the main branch, though.
Jeroen Ticheler wrote:
Hi PSC,
This is a motion for you to discuss and vote on related to a discussing on the list that clearly points to the need of a sandbox environment in SubVersion.
Justification:
Allow developers to use the GeoNetwork SVN as a place to store their new software developments within the sandbox.
This will help to keep projects aligned with the code on trunk and will also help to quickly merge new functions into trunk. By developing in a sandbox, other developers have an early chance to see what is been developed in the sandbox. This will make it easier to make, understand and discuss proposals for new functionality and will help to avoid forking.
How:
- We'll create a sandbox directory on SVN and add working copies of the trunk in there for those who want to work on a sandbox.
- Sandboxes should have a limited lifetime and be focussed on development of new functionality that is intended to be merged back into trunk when accepted by the PSC.
- New committers will be added to SVN in the understanding that they only work on the sandbox.
- Commit access to trunk is not given to them, unless they become approved committers to the trunk or have received the OK for an individual commit.
So I need one of you to second the motion and the others to vote.
Ciao,
Jeroen
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
--
Archie
-- Archie Warnock warnock@anonymised.com
-- A/WWW Enterprises www.awcubed.com
-- As a matter of fact, I _do_ speak for my employer.
+1.
Ciao. Francois
On mer, 2008-05-21 at 08:25 +0200, Jeroen Ticheler wrote:
Hi Cameron,
On May 20, 2008, at 10:17 PM, Cameron Shorter wrote:
> A few comments on admin, based on watching how the Openlayers sandbox
> has developed:
>
>> How:
>> - We'll create a sandbox directory on SVN and add working copies of
>> the trunk in there for those who want to work on a sandbox.
>>
> Developers should be able to create their own sandboxes. Eg:
> sandbox/ticheler/geonetwork/...
> or
> sandbox/bluenet/geonetwork/...
Yes! The only problem is that someone needs to give them access to SVN
in the first place It is indeed a good idea to use names as the
first level subdir under sandbox!
>
>> - Sandboxes should have a limited lifetime and be focussed on
>> development of new functionality that is intended to be merged back
>> into trunk when accepted by the PSC.
>>
> -1
> If a developer provides software worthy of the trunk, then yes, it can
> be removed from the sandbox.
> However, in Openlayers people have created experiemental branches, or
> project specific branches which have not made it back too the trunk
> and
> probably never will. However it is nice to keep them as reference for
> future.
OK, I have no problem with keeping them. At the same time I feel that
they should in principle be created with the idea to become inactive
after a while once the useful stuff has been merged.
Ciao,
Jeroen
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Hi all,
The below motion was passed with 6 PSC members voting in favor, one didn't vote.
I have now created the sandbox and added a geonetworkui location that will be used by Cameron Shorter, Roald de Wit and Simon Green to work on a new editor GUI.
Ciao,
Jeroen
On May 20, 2008, at 4:27 PM, Jeroen Ticheler wrote:
Hi PSC,
This is a motion for you to discuss and vote on related to a
discussing on the list that clearly points to the need of a sandbox
environment in SubVersion.
Justification:
Allow developers to use the GeoNetwork SVN as a place to store their
new software developments within the sandbox.
This will help to keep projects aligned with the code on trunk and
will also help to quickly merge new functions into trunk. By
developing in a sandbox, other developers have an early chance to see
what is been developed in the sandbox. This will make it easier to
make, understand and discuss proposals for new functionality and will
help to avoid forking.
How:
- We'll create a sandbox directory on SVN and add working copies of
the trunk in there for those who want to work on a sandbox.
- Sandboxes should have a limited lifetime and be focussed on
development of new functionality that is intended to be merged back
into trunk when accepted by the PSC.
- New committers will be added to SVN in the understanding that they
only work on the sandbox.
- Commit access to trunk is not given to them, unless they become
approved committers to the trunk or have received the OK for an
individual commit.
So I need one of you to second the motion and the others to vote.
Ciao,
Jeroen
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
one didn't vote.
That one is voting a +1 with a considerable delay...
Cheers,
Emanuele
Alle 15:41:14 di giovedì 29 maggio 2008, Jeroen Ticheler ha scritto:
Hi all,
The below motion was passed with 6 PSC members voting in favor, one
didn't vote.
I have now created the sandbox and added a geonetworkui location that
will be used by Cameron Shorter, Roald de Wit and Simon Green to work
on a new editor GUI.
Ciao,
Jeroen
On May 20, 2008, at 4:27 PM, Jeroen Ticheler wrote:
> Hi PSC,
> This is a motion for you to discuss and vote on related to a
> discussing on the list that clearly points to the need of a sandbox
> environment in SubVersion.
>
> Justification:
> Allow developers to use the GeoNetwork SVN as a place to store their
> new software developments within the sandbox.
> This will help to keep projects aligned with the code on trunk and
> will also help to quickly merge new functions into trunk. By
> developing in a sandbox, other developers have an early chance to see
> what is been developed in the sandbox. This will make it easier to
> make, understand and discuss proposals for new functionality and will
> help to avoid forking.
>
> How:
> - We'll create a sandbox directory on SVN and add working copies of
> the trunk in there for those who want to work on a sandbox.
> - Sandboxes should have a limited lifetime and be focussed on
> development of new functionality that is intended to be merged back
> into trunk when accepted by the PSC.
> - New committers will be added to SVN in the understanding that they
> only work on the sandbox.
> - Commit access to trunk is not given to them, unless they become
> approved committers to the trunk or have received the OK for an
> individual commit.
>
> So I need one of you to second the motion and the others to vote.
>
> Ciao,
> Jeroen
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> GeoNetwork-devel mailing list
> GeoNetwork-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> GeoNetwork OpenSource is maintained at
> http://sourceforge.net/projects/geonetwork
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
I didn't vote too. The motion email was dated 2008-05-29 15:40 and the motion passed email was dated the same day at 15:41. Was there a telecon?
Anyway, here is my +1
Cheers,
Andrea
> one didn't vote.
That one is voting a +1 with a considerable delay...
Cheers,
Emanuele
Alle 15:41:14 di giovedì 29 maggio 2008, Jeroen Ticheler ha scritto:
> Hi all,
> The below motion was passed with 6 PSC members voting in favor, one
> didn't vote.
>
> I have now created the sandbox and added a geonetworkui location that
> will be used by Cameron Shorter, Roald de Wit and Simon Green to work
> on a new editor GUI.
>
> Ciao,
> Jeroen
>
> On May 20, 2008, at 4:27 PM, Jeroen Ticheler wrote:
> > Hi PSC,
> > This is a motion for you to discuss and vote on related to a
> > discussing on the list that clearly points to the need of a sandbox
> > environment in SubVersion.
> >
> > Justification:
> > Allow developers to use the GeoNetwork SVN as a place to store their
> > new software developments within the sandbox.
> > This will help to keep projects aligned with the code on trunk and
> > will also help to quickly merge new functions into trunk. By
> > developing in a sandbox, other developers have an early chance to see
> > what is been developed in the sandbox. This will make it easier to
> > make, understand and discuss proposals for new functionality and will
> > help to avoid forking.
> >
> > How:
> > - We'll create a sandbox directory on SVN and add working copies of
> > the trunk in there for those who want to work on a sandbox.
> > - Sandboxes should have a limited lifetime and be focussed on
> > development of new functionality that is intended to be merged back
> > into trunk when accepted by the PSC.
> > - New committers will be added to SVN in the understanding that they
> > only work on the sandbox.
> > - Commit access to trunk is not given to them, unless they become
> > approved committers to the trunk or have received the OK for an
> > individual commit.
> >
> > So I need one of you to second the motion and the others to vote.
> >
> > Ciao,
> > Jeroen
Hi Andrea,
The motion was send on 20 May 
See below. You voted +1 on 22 May.
Ciao,
Jeroen
On May 30, 2008, at 7:21 PM, Andrea Carboni wrote:
I didn't vote too. The motion email was dated 2008-05-29 15:40 and the motion passed email was dated the same day at 15:41. Was there a telecon?
Anyway, here is my +1
Cheers,
Andrea
one didn't vote.
That one is voting a +1 with a considerable delay...
Cheers,
Emanuele
Alle 15:41:14 di giovedì 29 maggio 2008, Jeroen Ticheler ha scritto:
Hi all,
The below motion was passed with 6 PSC members voting in favor, one
didn't vote.
I have now created the sandbox and added a geonetworkui location that
will be used by Cameron Shorter, Roald de Wit and Simon Green to work
on a new editor GUI.
Ciao,
Jeroen
On May 20, 2008, at 4:27 PM, Jeroen Ticheler wrote:
Hi PSC,
This is a motion for you to discuss and vote on related to a
discussing on the list that clearly points to the need of a sandbox
environment in SubVersion.
Justification:
Allow developers to use the GeoNetwork SVN as a place to store their
new software developments within the sandbox.
This will help to keep projects aligned with the code on trunk and
will also help to quickly merge new functions into trunk. By
developing in a sandbox, other developers have an early chance to see
what is been developed in the sandbox. This will make it easier to
make, understand and discuss proposals for new functionality and will
help to avoid forking.
How:
- We'll create a sandbox directory on SVN and add working copies of
the trunk in there for those who want to work on a sandbox.
- Sandboxes should have a limited lifetime and be focussed on
development of new functionality that is intended to be merged back
into trunk when accepted by the PSC.
- New committers will be added to SVN in the understanding that they
only work on the sandbox.
- Commit access to trunk is not given to them, unless they become
approved committers to the trunk or have received the OK for an
individual commit.
So I need one of you to second the motion and the others to vote.
Ciao,
Jeroen
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork