Thanks to David for making a start. I have re-done the page based on his work.
http://hackage.haskell.org/trac/ghc/wiki/Contributors
Please look! I have begun with a statement about what being an "owner" means;
please help refine it.
Also I'm sure I have missed out areas that should be listed. Please edit.
David: pls add the Safe Haskell directories.
General opinions?
Simon
| -----Original Message-----
| From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org]
| On Behalf Of David Terei
| Sent: 12 December 2012 23:14
| To: Ben Lippmeier
| Cc: Ian Lynagh; cvs-ghc@haskell.org; Manuel M T Chakravarty
| Subject: Re: The end of an era, and the dawn of a new one
|
| 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).
|
| 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
