Posted by
Ray Barlow on
May 30, 2006; 1:46pm
URL: http://ofbiz.116.s1.nabble.com/Dev-this-week-s-development-blog-is-done-tp168137p168172.html
Given the success that the ASF have shown within the work that they
already do it would suggest that the change of perspective might not be
as bad as it sounds. Certainly control has to be handled through some
mechanism but by the very nature of giving a person any commit access
you are allowing them a level of trust, which they could abuse but it
wont really be in their interest to do so.
Peer review of changes will still take place and any one deemed to be
consistently miss using any trust they are given by the group/community
can also have that access removed. Certainly committers should be clear
about the modules they can commit to and who other modules are owned by
and they should seek clearance before committing changes outside of
their scope.
You could suggest that this also might save the core developers (module
owners) a small amount of time, depending on the change how they review
it. For changes where they can review just the patch file direct they
will only need to give the all clear and the submitter can then take
care of committing, saving the reviewer the time taken to download,
apply and commit the patch with comments etc.
Ray
David Welton wrote:
>On 5/30/06, Andrew Sykes <
[hidden email]> wrote:
>
>
>
>>On Tue, 2006-05-30 at 11:36 +0200, David Welton wrote:
>>
>>
>>>A consistent part of the answers I got from the ASF folks indicate
>>>that subdividing permissions within a project isn't viewed all that
>>>well.
>>>
>>>
>>Given the scale of OFBiz, it's not just a case of people asking when
>>they don't know how something works, but also when they think they do.
>>There are any number of examples of patches that look perfectly fine to
>>an outside observer, but to the person who owns that part of the code,
>>they are far from that.
>>
>>
>>I'm rather nervous at the idea of commit privileges changing, because
>>they form part of a fairly mature way of working and would probably
>>adversely effect QA.
>>
>>
>>OFBiz developers are under time pressure from the projects that fund
>>OFBiz development. Offering a route to circumvent the normal commit
>>process is probably a bad thing as it would most likely reduce scrutiny.
>>
>>
>
>Like I said, if the consensus is not to change, it certainly won't be
>forced on you - I was suggesting that it might be an opportune moment
>to reflect on whether it's the best way forward.
>
>Clearly, utilizing svn permissions has advantages in terms of control
>and helping people to 'avoid temptation'. One might make the counter
>argument that in a group like the ASF, the preferred way of working is
>to create the right community climate so that people are discouraged
>from doing the 'wrong thing' via social pressure, respect for, and
>trust in the next guy rather than a technical barrier. Not to say
>that those things are lacking if the technical barrier is the
>preferred route, but perhaps it becomes more critical to foster them
>to ensure the smooth flow of development.
>
>
>
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev