On 12 December 2012 16:08, Manuel M T Chakravarty <c...@cse.unsw.edu.au> wrote:
> David Terei <davidte...@gmail.com>:
>> So I had a go at updating the wiki page to reflect ownership / tsar
>> status / maintainers.
>>
>> http://hackage.haskell.org/trac/ghc/wiki/Contributors
>>
>> This page will probably need to change when reach a conclusion of how
>> we want to frame this responsibility (i.e., owners, maintainers,
>> tsars).
>>
>> The list of people is very light right now as I only put down people
>> who had said they would take ownership of a task. (although I did make
>> assumptions for Ian, Simon PJ & Simon M).
>
> I edited it a bit. Weren't there some people who volunteered as performance 
> tsars?

Added in.

>
> I still think the directory to maintainer mapping makes no sense.

Yes, I agree. I thought it would work but after trying it, it
doesn't feel like it did. I left it in so that others can play
around with for now.

>
> Manuel
>
>> On 9 December 2012 16:53, Ben Lippmeier <b...@ouroborus.net> wrote:
>>>
>>> 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
>>
>> _______________________________________________
>> Cvs-ghc mailing list
>> Cvs-ghc@haskell.org
>> http://www.haskell.org/mailman/listinfo/cvs-ghc
>

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

Reply via email to