[mapguide-internals] MapGuide RFC 57 - Refining the linuxbuildprocess and generating install packages

[Tom Fukushima]

This page talks about how to become a contributor: http://mapguide.osgeo.org/developer.html

Note the statements:
Project Developers can nominate a Project Contributor who has sent in solid, useful patches for Project Developer status. The PSC then votes to officially elect the individual to Project Developer status, at which time commit rights are granted.

But I think that for install and build work, we are willing to forgo the above prerequisite for patches with the caveat that the submissions will be limited to the build work in the sandbox (and for the merge when back to trunk when it is done and approved).

Tom

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
Sent: Wednesday, November 26, 2008 2:44 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] MapGuide RFC 57 - Refining the linuxbuildprocess and generating install packages

Jason, that makes sense with regards to trac, I've been knee deep in JIRA for
a while and we approach things a bit differently given the extra
flexibility that
JIRA provides (primarily multiple components, affects version(s) and
fix version(s) . )

that also makes complete sense with regards to requiring the
contributors agreement
http://wiki.osgeo.org/wiki/Contributor_Agreement

Thanks for the info Frank about subversion

Is there anything else we need to discuss prior to putting the up for
a PSC vote?

The only thing is approval process for the sandboxers... how does that work?

if you have an a valid osgeo contributors agreement and want to get
in, you get access?

z




On Thu, Nov 27, 2008 at 8:26 AM, Jason Birch <Jason.Birch at nanaimo.ca> wrote:
> I feel that we could give sandbox committers full access and expect them
> to "do the right thing".  My personal take is that if we do this we
> should require that our sandbox committers sign a contribution agreement
> though.
>
> Other projects like gdal and openlayers create the sandbox at the same
> level as trunk, branches, etc, and as far as I know don't set up Trac
> components for the sandbox.  We could either overload the "Build"
> component, or create a new component for CMake I guess.
>
> Jason
>
> -----Original Message-----
> From: Zac Spitzer
> Sent: Wednesday, November 26, 2008 13:10
> Subject: Re: [mapguide-internals] MapGuide RFC 57 - Refining the
> linuxbuildprocess and generating install packages
>
> With regards to undertaking this work in a sandbox, how is that going
> to work with commit rights?
>
> Will SVN ACL's be used to provide commit access to the people working
> on the sandbox
> without giving the commit access to the whole tree?
>
> As it was mentioned that 2.1 was going to appear as a beta (back in
> oct?) is the trunk in a
> reasonable state for branching off into a sandbox?
>
> What's the best approach with trac? a special milestone?
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>



--
Zac Spitzer -
http://zacster.blogspot.com
+61 405 847 168
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals