Re: The end of an era, and the dawn of a new one
David Terei <davidterei <at> gmail.com>
2012-12-13 03:33:06 GMT
On 12 December 2012 16:08, Manuel M T Chakravarty <chak <at> cse.unsw.edu.au> wrote:
> David Terei <davidterei <at> gmail.com>:
>> So I had a go at updating the wiki page to reflect ownership / tsar
>> status / maintainers.
>> This page will probably need to change when reach a conclusion of how
>> we want to frame this responsibility (i.e., owners, maintainers,
>> 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?
> 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.
>> On 9 December 2012 16:53, Ben Lippmeier <benl <at> ouroborus.net> wrote:
>>> On 09/12/2012, at 10:53 PM, Manuel M T Chakravarty wrote:
>>>> Ian Lynagh <ian <at> 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.
>>> Cvs-ghc mailing list
>>> Cvs-ghc <at> haskell.org
>> Cvs-ghc mailing list
>> Cvs-ghc <at> haskell.org