Re: The end of an era, and the dawn of a new one

Ahh that is much better than my initial attempt! Safe Haskell directories added.

On 15 December 2012 00:46, Simon Peyton-Jones <[email protected]> wrote:
> 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: [email protected] [mailto:[email protected]]
> | On Behalf Of David Terei
> | Sent: 12 December 2012 23:14
> | To: Ben Lippmeier
> | Cc: Ian Lynagh; [email protected]; 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 <[email protected]> wrote:
> | >
> | > On 09/12/2012, at 10:53 PM, Manuel M T Chakravarty wrote:
> | >
> | >> Ian Lynagh <[email protected]>:
> | >>> 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
> | > [email protected]
> | > http://www.haskell.org/mailman/listinfo/cvs-ghc
> |
> | _______________________________________________
> | Cvs-ghc mailing list
> | [email protected]
> | http://www.haskell.org/mailman/listinfo/cvs-ghc