On 09/12/2012, at 10:53 PM, Manuel M T Chakravarty wrote:

> Ian Lynagh <i...@well-typed.com>:
>> On Thu, Dec 06, 2012 at 12:32:05PM +0000, Simon Peyton-Jones wrote:
>>> (Narrowing to cvs-ghc for now.)
>>> 
>>> Speaking for myself, I would welcome a code-ownership model along the lines 
>>> that Ben suggests. If it works well it would
>>> a) spread the load
>>> b) broaden a genuine sense of ownership
>>> c) because of (a) and (b), perhaps encourage more people to participate
>>> 
>>> What do others think?
>> 
>> "owner" is a very strong word: I think other projects have had problems
>> where e.g. owners have found themselves without time to deal with
>> patches submitted, but have been unwilling to let anyone else touch
>> "their" code.
>> 
>> Perhaps we could have "maintainers" instead?
> 
> I agree with Ian here. 
> 
> Code ownership is not necessarily a Good Thing. In fact, it is often 
> discouraged in modern approaches to software engineering. Why? Because it 
> creates a barrier for the non-owners to contribute to a code base, especially 
> if we would start to introduce procedures such as an obligation for the owner 
> to review all patches to *their* code base.

I agree that having a "Ownership" model may increase the barrier to new 
contributors submitting drive-by patches, but at the same time it reduces the 
barrier to the owner performing more wide ranging changes and refactorings.

If I'm a drive-by contributor or assigned maintainer, then I'm probably not 
going to spend a week of my own time refactoring, documenting, and cleaning up 
all the native code generators, because it's not my project. However, if I were 
to make a conscious decision to assume responsibility for that code for (say) a 
year, I'd go though and clean it all up. Maintenance is largely a thankless 
task because it doesn't lead to a sexy feature or support for a new platform. 
It does improve the overall health of the project, though. Having successive 
people assume ownership, and then going though and auditing all the code would 
be even better.


> This is particularly awkward in an open source project. If somebody is busy 
> (or on holidays) for a month, nobody can push patches that touch that code.

I don't think going to an Ownership model need prevent people with accounts on 
d.h.o continuing to change whatever code they need to. If I were to assume 
responsibility for some code I'm not going to require Simon(s) or Johan to 
submit patches to me for review. It's true that some contributed patches may 
languish on the trac for a few weeks, but that happens anyway.


> I like the "Tsar" idea that SPJ started with the Performance Tsar(s). Instead 
> of assigning ownership of code (like in a land grab), let's define areas of 
> responsibility. Many of these responsibilities (like performance) will touch 
> on a cross section of the code base.


My worry is that having a responsibility without a corresponding asset feels 
more like a job than a fun thing to do. The "asset" here is more of an 
emotional construct than a physical one -- a sense of "this is mine to look 
after".

Code maintenance isn't fun, and given the choice I'd prefer to work on my own 
projects than documenting someone else's code. If you say "you can be 
responsible for the performance of GHC" that's a fairly nebulous concept, but 
if you say "this code is yours for a year, look after it", then it gives the 
owner some immediate, well defined, concrete goals.

It's the tragedy of the commons. Without a sense of ownership, people won't 
take real responsibility.

Ben.


_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to