[mapguide-internals] Commit rights for UV

Fri May 8 08:19:49 EDT 2009

Some random thoughts on this thread ...

One of the great features of a version control system is that it is  
easy to roll back changes that didn't work out or were perhaps ill- 
advised.  What is the real risk here of allowing folks to commit?  I  
suspect that the risks are more theoretical than real.

On a side note, Google Code has a review tool which is, interestingly,  
hooked to code that has already been committed rather than to a queue  
of patches awaiting submission.

On the sandbox thing, if we allow interested developers commit access  
and just ask them not to commit to trunk without review that would  
probably suffice.  The number of interested developers is countable on  
one hand of a woodworker who has had several accidents ...

One other thought, I think that if code is committed, it is more  
likely to receive a review in a realistic time frame too ;)

I personally haven't reviewed UV's code, nor would I be right person  
to do so, but it seems from at least some of the comments that it  
represents a substantial investment in time to understand the nature  
of a problem in the code and fix it.  Sounds like we need people like  
this in the project ...

I guess what I am driving at is that I am in favour of being more  
permissive rather than less, given that the actual risk is much lower  
than the perceived risk

Paul

On 7-May-09, at 11:45 PM, Zac Spitzer wrote:

> that plugin looks like a great idea! it's good for capturing the  
> knowledge
> as well for new developers to get involved.
>
> Jason mentioned that we can do the sandbox only commit access,
> it's just a simple enough change to the svn acl file which is  
> basically
> you define a group and assign it RW to a svn folder
>
> z
>
> On Fri, May 8, 2009 at 1:40 PM, Trevor Wekel
> <trevor_wekel at otxsystems.com> wrote:
>> I wonder if an online code collaboration tool would be of benefit to
>> MapGuide and OSGeo.  Even developers with commit rights should be  
>> getting
>> code reviews from other developers.  We do this internally at  
>> Autodesk but
>> there is currently no mechanism to do this easily with the external
>> community.  There is a "trac hack" available which might be  
>> appropriate.
>>
>> http://trac-hacks.org/wiki/PeerReviewPlugin
>>
>>
>> I don't know if it is possible to grant commit rights to the  
>> sandbox only.
>> It would make the commit rights approval more transparent if code  
>> could be
>> checked into sandbox and then reviewed.  If not, perhaps we can  
>> simply add
>> the code review comments to the tickets which contain the patches.
>>
>> Thanks,
>> Trevor
>>
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org
>> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
>> Sent: Thursday, May 07, 2009 8:28 PM
>> To: MapGuide Internals Mail List
>> Subject: Re: [mapguide-internals] Commit rights for UV
>>
>> Currently, the process is only poorly defined and does not state very
>> clear rules in particular in regards of timing.
>>
>> Can someone jump in (from the PSC i guess) review my code and  
>> provide me
>> some feedback, I've been working on this for a while now and I would
>> like to know how close I am to getting commit rights?
>> The several patches requirement is a little loose, as for RFC60  
>> there is
>> one big patch, which could be seen as a equivalent to several smaller
>> patches? And there are other contributions regarding other issues  
>> which
>> show further insight into the server code.
>>
>>
>> Zac Spitzer wrote:
>>> Just been reading the PSC notes, sorry I couldn't make the session,
>>> waaayy to late down under..
>>>
>>> I am rather worried about the trend that UV after posting a RFC
>>> and then actually implementing it, plus his work on the build stuff
>>> plus numerous other small issues he delved into and has found
>>> solutions for, still isn't being considered for commit rights as
>>> per the notes from the PSC...
>>>
>>> How high is the barrier for entry? Where are the PSC members
>>> actively supporting new developers and guiding them into moving
>>> forward to commit status.
>>>
>>> This seems to of happened with both Helio and UV, both have stepped
>>> up, dived deep into the code base but are still 'locked out'
>>>
>>> I think the PSC needs to be way more active in this regard if  
>>> MapGuide is
>>> going to succeed as an open source project.
>>>
>>> Initially with UV, the feedback from the Autodesk team was that they
>>> where reluctant to guide new developers until they proved their
>> commitment.
>>>
>>> There is a certain level of irony in the PSC notes, where on one  
>>> hand it
>>> has been said that UV is not ready for commit rights, but at the  
>>> same
>> time, he
>>> has done the work on working out failed tiled stuff which was no  
>>> minor
>> effort
>>> in itself and the PSC then suggesting that he should write a RFC  
>>> for it..
>>>
>>> That seems rather contradictory.
>>>
>>> Moving forward, can I ask for someone in the PSC take a direct  
>>> involvement
>>> in regards to commit rights for UV?
>>>
>>> z
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>> _______________________________________________
>> 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

__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://research.dmsolutions.ca/