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
