[mapguide-internals] Motion: Give developers commit rights to work in a sandbox

[Tom Fukushima]

Jason,

In case you are saying that I'm thinking that giving Hugues, Jon and Norm full access "felt a bit out of place given the difficulty getting commit rights for UV".  This is totally 100% not what I'm thinking.  As I think we all know now, I'm only saying that they need access to the sandbox --- that's it.
 
There are more developers here (for example, Christine) who would like commit access to the MGOS vault, but we are putting them through the standard process of providing patches first.  There is no favoritism. Let's stop any thoughts that there might be immediately.

There is no need to reply to this email, it is for clarification purposes only.

PSC,

One other point of clarification.  According to the committers list, Jon is already a committer in the MapGuide vault,  he worked on the original 1.0 versions of MapGuide. Sorry, that I added him to the original list. If you see him making submissions to other branches, that's because he can (I'm assuming that we are going with the PFOSS book rule of not removing committers even if they have been dormant for a while).

Tom



-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Thursday, June 25, 2009 3:46 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Motion: Give developers commit rights to work in a sandbox

I'm not Kenneth, but... :)

You've cleared this up since, but your initial email where you talked about giving full commit rights felt a bit out of place given the difficulty getting commit rights for UV (which BTW I still feel was appropriate given that he was also essentially unknown to the community).  It may not have been your intention, but this did sound to me like "They work for Autodesk, and I trust them, so they should have access".  I think the general sandbox approach is fine, just that the initial message may have been misinterpreted.

I also agree with Paul that sandboxes should be available to anyone who needs one, but I wonder if there should be a specific reason (such as, overhauling the projection library, or integrating a REST extension, or writing a Flex-based client, or maintaining a custom branch for some product).  This has the benefit of making sandbox creation more about the function than about the person.  This is more about controlling the size of the repository than about trust / usefulness.  Once created, we could have an open-door policy about commit rights, but with the understanding that any code integrated into trunk would first require both a CLA and community review.  I guess I'm not really opposed to person-based sandboxes, but I can't think of a use case that project-based sandboxes wouldn't cover.

Jason

-----Original Message-----
From: Tom Fukushima
Sent: Thursday, June 25, 2009 1:36 PM
Subject: RE: [mapguide-internals] Motion: Give developers commit rights to work in a sandbox

Kenneth,

Wow,  I'm sorry if I'm being dense, but I really don't know where this favoritism feeling is coming from.

Let me back up a bit... MGOS doesn't have a process for the sandbox, and so I thought I was doing the right thing by making sure to ask the PSC for the rights to the sandbox for some developers.  So yes, we need to vote or do something. What did I do wrong to get so much concern about this request? Please tell me, I would like to know? Should I just tell the developers that they should forget this approach?

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals