http://ofbiz.116.s1.nabble.com/Dev-this-week-s-development-blog-is-done-tp168137p168173.html
I was pretty resistant to this more global approach at first, but am warming to it as a possibility... especially since OFBiz is becoming more and more committee driven.
Before going on I should that I've tried to discourage the "ownership" idea of any of the code in OFBiz, regardless of who wrote it or is current working on or maintaining it.
The real point, and this I think is somewhat new for an Apache project, is that OFBiz is fairly large and different parts require very different expertise and knowledge. As Andrew pointed out issues can (and have a bit...) arise from people not having sufficient experience with something and putting in something they think is fine.
It is true that the commits are monitored by various people, and that is why I'm considering this going forward. Even with the current technical controls there have been instances where something less than ideal was committed that served a particular need, perhaps for a particular client, but broke other more general things that were more important. These have resulted in discussion and being fixed, and hopefully that will continue (and in some cases with less friction... ;) ).
I, and probably others, would be much more comfortable with this if there was at least a distinction between the framework and the applications, and perhaps that will come in the near future as we've been talking about splitting these for a long time. If we get a TLP position then maybe we'll get these split out as sub-projects with separate repositories or something...
> 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