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
