Simon Peyton-Jones | 5 Dec 17:56 2012
Picon

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

Friends

You'll have seen Simon Marlow's recent announcement (included below):

| Today I'm announcing that I'm leaving Microsoft Research.

Simon Marlow and I have worked together on GHC for nearly two decades.
During much of that time we have shared a cup of coffee every morning
(one cup each, since you ask), to discuss what's going on in
GHC-land.  We had frequent detailed and illuminating debates
about design alternatives. Simon is the absolute master of GHC's
code generation, runtime system, garbage collector, support for
parallel execution, and much else besides.  His sheer programming
skill in rooting out obscure and hard-to-reproduce runtime system
bugs has always amazed me.  He is more than just a great hacker,
of course.  He is a leader in our community, has a strong
publication record, chaired the Haskell Prime committee for a
year, and is sought after for tutorials about parallel
programming.

I owe Simon a great debt, as I think we all do, for the care and
skill he has lavished on GHC.  He's not going to disappear
entirely, but he will be spending much less time on GHC than in
the past.  That is a change, but it's a change that was always
going to happen sometime, and while change is sometimes
uncomfortable, it can also open up new possibilities.

GHC is over 20, and like my own children (who are actually all a bit
younger than GHC), that's not a bad time to start to head out into the
world.  Over time, more and more people have started to help with the
(Continue reading)

David Terei | 5 Dec 21:37 2012
Picon

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

I have always considered the LLVM code generator my responsibility and
will continue to do so. I don't seem to find the time to make
improvements to it but make sure to keep it bug free and working with
the latest LLVM releases. So if others want are interested in working
on it then there is plenty of room for that but I'll continue to
maintain it and be responsible for it at the least.

On 5 December 2012 08:56, Simon Peyton-Jones <simonpj <at> microsoft.com> wrote:
> Friends
>
> You'll have seen Simon Marlow's recent announcement (included below):
>
> | Today I'm announcing that I'm leaving Microsoft Research.
>
> Simon Marlow and I have worked together on GHC for nearly two decades.
> During much of that time we have shared a cup of coffee every morning
> (one cup each, since you ask), to discuss what's going on in
> GHC-land.  We had frequent detailed and illuminating debates
> about design alternatives. Simon is the absolute master of GHC's
> code generation, runtime system, garbage collector, support for
> parallel execution, and much else besides.  His sheer programming
> skill in rooting out obscure and hard-to-reproduce runtime system
> bugs has always amazed me.  He is more than just a great hacker,
> of course.  He is a leader in our community, has a strong
> publication record, chaired the Haskell Prime committee for a
> year, and is sought after for tutorials about parallel
> programming.
>
> I owe Simon a great debt, as I think we all do, for the care and
> skill he has lavished on GHC.  He's not going to disappear
(Continue reading)

Johan Tibell | 5 Dec 21:42 2012
Picon

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

On Wed, Dec 5, 2012 at 12:37 PM, David Terei <davidterei <at> gmail.com> wrote:
> I have always considered the LLVM code generator my responsibility and
> will continue to do so. I don't seem to find the time to make
> improvements to it but make sure to keep it bug free and working with
> the latest LLVM releases. So if others want are interested in working
> on it then there is plenty of room for that but I'll continue to
> maintain it and be responsible for it at the least.

I will maintain the I/O manager as per usual, probably together with
Bryan and Andreas (but I cannot speak for them of course).
Ian Lynagh | 6 Dec 18:27 2012

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

On Wed, Dec 05, 2012 at 12:42:33PM -0800, Johan Tibell wrote:
> 
> I will maintain the I/O manager as per usual

Excellent, thanks!

There are a couple of tickets that are currently assigned to me that
look like they might be IO manager bugs:
    http://hackage.haskell.org/trac/ghc/ticket/4245
    http://hackage.haskell.org/trac/ghc/ticket/7133

I'm unlikely to have time to look at either of them in the near future,
so please feel free to reassign them to yourself and take a look.

Thanks
Ian
Ian Lynagh | 6 Dec 18:37 2012

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

On Wed, Dec 05, 2012 at 12:37:22PM -0800, David Terei wrote:
> I have always considered the LLVM code generator my responsibility and
> will continue to do so.

Great, thanks!

> I don't seem to find the time to make
> improvements to it but make sure to keep it bug free and working with
> the latest LLVM releases. So if others want are interested in working
> on it then there is plenty of room for that but I'll continue to
> maintain it and be responsible for it at the least.

And of course, if anyone does find themselves looking for an
LLVM-related ticket to fix, there's a component for them in trac:
    http://hackage.haskell.org/trac/ghc/query?status=infoneeded&status=new&status=patch&component=Compiler+%28LLVM%29

Thanks
Ian
Ben Lippmeier | 6 Dec 11:56 2012
Picon

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


On 06/12/2012, at 3:56 , Simon Peyton-Jones wrote:

> Particularly valuable are offers to take responsibility for a
> particular area (eg the LLVM code generator, or the FFI).  I'm
> hoping that this sea change will prove to be quite empowering,
> with GHC becoming more and more a community project, more
> resilient with fewer single points of failure. 

The LLVM project has recently come to the same point. The codebase has become too large for Chris Lattner to
keep track of it all, so they've moved to a formal "Code Ownership" model. People own particular
directories of the code base, and the code owners are expected to review patches for those directories.

The GHC project doesn't have a formal patch review process, I think because the people with commit access on
d.h.o generally know who owns what. Up until last week I think it was "SPJ owns the type checker and
simplifier, and SM owns everything else." :-)

At this stage, I think it would help if we followed the LLVM approach of having a formal CODE_OWNERS file in
the root path of the repo explicitly listing the code owners. That way GHC HQ knows what's covered and what
still needs a maintainer. The LLVM version is here [1].

Code owners would:
1) Be the go-to person when other developers have questions about that code.
2) Fix bugs in it that no-one else has claimed.
3) Generally keep the code tidy, documented and well-maintained.

Simon: do you want a CODE_OWNERS file? If so then I can start it. I think it's better to have it directly in the
repo than on the wiki, that way no-one that works on the code can miss it.

I suppose I'm the default owner of the register allocators and non-LLVM native code generators.
(Continue reading)

Simon Peyton-Jones | 6 Dec 13:32 2012
Picon

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

(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?

Simon

| -----Original Message-----
| From: Ben Lippmeier [mailto:benl <at> ouroborus.net]
| Sent: 06 December 2012 10:57
| To: Simon Peyton-Jones
| Cc: haskell; glasgow-haskell-users <at> haskell.org; Haskell Cafe (haskell-
| cafe <at> haskell.org); Simon Marlow
| Subject: Re: The end of an era, and the dawn of a new one
| 
| 
| On 06/12/2012, at 3:56 , Simon Peyton-Jones wrote:
| 
| > Particularly valuable are offers to take responsibility for a
| > particular area (eg the LLVM code generator, or the FFI).  I'm hoping
| > that this sea change will prove to be quite empowering, with GHC
| > becoming more and more a community project, more resilient with fewer
| > single points of failure.
| 
| The LLVM project has recently come to the same point. The codebase has
(Continue reading)

Johan Tibell | 6 Dec 16:08 2012
Picon

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

On Dec 6, 2012 4:39 AM, "Simon Peyton-Jones" <simonpj <at> microsoft.com> 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?

Sounds like a good idea.

_______________________________________________
Cvs-ghc mailing list
Cvs-ghc <at> haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Simon Marlow | 6 Dec 17:25 2012
Picon

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

On 06/12/12 15:08, Johan Tibell wrote:
> On Dec 6, 2012 4:39 AM, "Simon Peyton-Jones" <simonpj <at> microsoft.com
> <mailto:simonpj <at> microsoft.com>> 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?
>
> Sounds like a good idea.

Yes, I think it's a great idea.  I'm happy to be listed as the owner for 
my bits for the time being, until/unless others are able to take over.

Cheers,
	Simon
Ian Lynagh | 6 Dec 17:32 2012

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

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?

We actually already have something similar to this proposal here:
    http://hackage.haskell.org/trac/ghc/wiki/Contributors
although it's quite out-of-date, mostly because people tend to fade away
rather than have a definite date on which they stop maintaining
something.

Thanks
Ian
Johan Tibell | 6 Dec 17:42 2012
Picon

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

On Thu, Dec 6, 2012 at 8:32 AM, Ian Lynagh <ian <at> well-typed.com> wrote:
> Perhaps we could have "maintainers" instead?

If maintenance can be defined on a per-directory level we can put a
MAINTAINERS file in listing maintainers for a directory and all its
subdirectories. For example,

    ghc/MAINTAINERS would contain
        simonpj
        simonmar

    libraries/base/GHC/Event/MAINTAINERS would contain
        tibbe
        bos

    ghc/compiler/llvmGen would contain
        benl
        davidterei

and so on. To find a maintainer (e.g. to send a request for code
review to) you follow the directory hierarchy upwards, starting from
the directory in which you want to make modifications, until you find
a MAINTAINERS file. You then pick one of the maintainers there and
assign the ticket with the attached code for them to review.

Perhaps this is a bit too involved given the number of people involved.

-- Johan
David Terei | 6 Dec 22:49 2012
Picon

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

I think that sounds too involved. How many maintainers would we really
be looking at at this point? I think only around 5 - 10 really. So a
single file in the root seems easiest.

The other concern is some components of GHC are all over the place.
I'm also the maintainer for Safe Haskell and that involves code in a
few different folders.

On 6 December 2012 08:42, Johan Tibell <johan.tibell <at> gmail.com> wrote:
> On Thu, Dec 6, 2012 at 8:32 AM, Ian Lynagh <ian <at> well-typed.com> wrote:
>> Perhaps we could have "maintainers" instead?
>
> If maintenance can be defined on a per-directory level we can put a
> MAINTAINERS file in listing maintainers for a directory and all its
> subdirectories. For example,
>
>     ghc/MAINTAINERS would contain
>         simonpj
>         simonmar
>
>     libraries/base/GHC/Event/MAINTAINERS would contain
>         tibbe
>         bos
>
>     ghc/compiler/llvmGen would contain
>         benl
>         davidterei
>
> and so on. To find a maintainer (e.g. to send a request for code
> review to) you follow the directory hierarchy upwards, starting from
> the directory in which you want to make modifications, until you find
> a MAINTAINERS file. You then pick one of the maintainers there and
> assign the ticket with the attached code for them to review.
>
> Perhaps this is a bit too involved given the number of people involved.
>
> -- Johan
>
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc <at> haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc
Johan Tibell | 6 Dec 23:07 2012
Picon

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

On Thu, Dec 6, 2012 at 1:49 PM, David Terei <davidterei <at> gmail.com> wrote:
> I think that sounds too involved. How many maintainers would we really
> be looking at at this point? I think only around 5 - 10 really. So a
> single file in the root seems easiest.
>
> The other concern is some components of GHC are all over the place.
> I'm also the maintainer for Safe Haskell and that involves code in a
> few different folders.

Fair enough. A single file sounds fine to me.
Ian Lynagh | 7 Dec 15:55 2012

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

On Thu, Dec 06, 2012 at 01:49:32PM -0800, David Terei wrote:
> I think that sounds too involved. How many maintainers would we really
> be looking at at this point? I think only around 5 - 10 really. So a
> single file in the root seems easiest.

A wiki page feels like a more appropriate place to me, because generally
you want to know who the current owner is, rather than who the owner was
at the time your tree is from (if you're looking at the GHC 7.4 tarball,
or if you've gone back in the git history).

Updating a wiki page would also feel lighter-weight to me, so perhaps it
would be easier to keep up-to-date.

We might also have owners of things that aren't in the code tree, e.g.
the website, trac, and the mailing lists.

Either way, perhaps the best way forward would be for someone to bring
    http://hackage.haskell.org/trac/ghc/wiki/Contributors
up-to-date. We could also rename it to Owners if we stick with a wiki
page. It's currently linked as "The GHC Team" from the
    http://www.haskell.org/ghc/
site, and as "GHC Contributors" from the
    http://hackage.haskell.org/trac/ghc/
site.

Thanks
Ian
Ben Lippmeier | 7 Dec 01:29 2012
Picon

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


On 07/12/2012, at 3:32 AM, Ian Lynagh wrote:

> 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.

Personally, I don't think we'll have problems with this. A prerequisite for code ownership would be to have
an account on d.h.o and I think (almost) everyone on that list knows each other personally.

A point about using the "owner" label is that it makes the person directly responsible for the quality of
their code base. I think up until now the "contributors" have been working under a pretence of "I'll help
out where I can, but it's not really my responsibility". In contrast, if you make someone a code owner you
trust them to be committed to the good of the project.

We would want the new code owners to make an initial time investment in going though and cleaning up /
understanding their code. If that means they're not prepared to accept some half-baked patches due to the
increased maintenance burden, then so be it. I think GHC HQ occasionally palms off contributed patches
for this reason anyway.

> We actually already have something similar to this proposal here:
>    http://hackage.haskell.org/trac/ghc/wiki/Contributors
> although it's quite out-of-date, mostly because people tend to fade away
> rather than have a definite date on which they stop maintaining
> something.

Having a specified end-date is a good idea. Maybe people should take ownership of some code for periods of
one year at a time, and then don't need to feel bad if their circumstances change and they don't have time for
it anymore.

Ben.
Simon Peyton-Jones | 7 Dec 08:56 2012
Picon

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

| "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 like "owner" exactly because it is strong. It encourages a sense of, well, ownership.  "Maintainer"
sounds more like a service role.

I think we can put words around it that make it clear what we have in mind. It's a first-among-equals role, not
total control.  But I'd be happy to learn from other projects.

Simon
Manuel M T Chakravarty | 9 Dec 12:53 2012
Picon
Picon

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

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.

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.

GHC's development model always struck me as rather anarchic, and it has worked well for GHC. Of course, it is
common courtesy to discuss any major changes or new language features with all stake holders. That has
always been the case and, I am sure, we'll continue that.

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.

Manuel
Ben Lippmeier | 10 Dec 01:53 2012
Picon

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


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.

Ben.
David Terei | 13 Dec 00:14 2012
Picon

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 <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.
>
> Ben.
>
>
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc <at> haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc
Manuel M T Chakravarty | 13 Dec 01:08 2012
Picon
Picon

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

David Terei <davidterei <at> 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?

I still think the directory to maintainer mapping makes no sense.

Manuel

> 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.
>> 
>> Ben.
>> 
>> 
>> _______________________________________________
>> Cvs-ghc mailing list
>> Cvs-ghc <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/cvs-ghc
> 
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc <at> haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc
David Terei | 13 Dec 04:33 2012
Picon

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

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.
>>
>> 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 <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.
>>>
>>> Ben.
>>>
>>>
>>> _______________________________________________
>>> Cvs-ghc mailing list
>>> Cvs-ghc <at> haskell.org
>>> http://www.haskell.org/mailman/listinfo/cvs-ghc
>>
>> _______________________________________________
>> Cvs-ghc mailing list
>> Cvs-ghc <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/cvs-ghc
>
Simon Peyton-Jones | 14 Dec 14:46 2012
Picon

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

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-bounces <at> haskell.org [mailto:cvs-ghc-bounces <at> haskell.org]
| On Behalf Of David Terei
| Sent: 12 December 2012 23:14
| To: Ben Lippmeier
| Cc: Ian Lynagh; cvs-ghc <at> 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 <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.
| >
| > Ben.
| >
| >
| > _______________________________________________
| > Cvs-ghc mailing list
| > Cvs-ghc <at> haskell.org
| > http://www.haskell.org/mailman/listinfo/cvs-ghc
| 
| _______________________________________________
| Cvs-ghc mailing list
| Cvs-ghc <at> haskell.org
| http://www.haskell.org/mailman/listinfo/cvs-ghc
Ian Lynagh | 14 Dec 16:06 2012

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

On Fri, Dec 14, 2012 at 01:46:42PM +0000, Simon Peyton-Jones wrote:
> 
> Please look!  I have begun with a statement about what being an "owner" means; please help refine it.

Perhaps add something like:

    It does not mean that the owner can make decisions that the
    community disagrees with. While being willing to roll your sleeves
    up does lend weight to your voice, owners should aim to find
    consensus for contentious issues.

?

> General opinions?

Generally looks good.

I'm not sure if giving e-mail addresses for owners is a good idea.
Shouldn't messages still be sent to cvs-ghc <at> , so that other people can
weigh in if they have an opinion, or reply if the owner isn't around?

Thanks
Ian
--

-- 
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
Simon Peyton-Jones | 14 Dec 16:13 2012
Picon

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

Done.  I think we still want the email addresses but I've suggested ccing ghc-devs.

Incidentally when will ghc-devs go live?

S

| -----Original Message-----
| From: cvs-ghc-bounces <at> haskell.org [mailto:cvs-ghc-bounces <at> haskell.org]
| On Behalf Of Ian Lynagh
| Sent: 14 December 2012 15:06
| To: cvs-ghc <at> haskell.org
| Subject: Re: The end of an era, and the dawn of a new one
| 
| On Fri, Dec 14, 2012 at 01:46:42PM +0000, Simon Peyton-Jones wrote:
| >
| > Please look!  I have begun with a statement about what being an
| "owner" means; please help refine it.
| 
| Perhaps add something like:
| 
|     It does not mean that the owner can make decisions that the
|     community disagrees with. While being willing to roll your sleeves
|     up does lend weight to your voice, owners should aim to find
|     consensus for contentious issues.
| 
| ?
| 
| > General opinions?
| 
| Generally looks good.
| 
| I'm not sure if giving e-mail addresses for owners is a good idea.
| Shouldn't messages still be sent to cvs-ghc <at> , so that other people can
| weigh in if they have an opinion, or reply if the owner isn't around?
| 
| 
| Thanks
| Ian
| --
| Ian Lynagh, Haskell Consultant
| Well-Typed LLP, http://www.well-typed.com/
| 
| _______________________________________________
| Cvs-ghc mailing list
| Cvs-ghc <at> haskell.org
| http://www.haskell.org/mailman/listinfo/cvs-ghc
Ian Lynagh | 14 Dec 17:42 2012

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

On Fri, Dec 14, 2012 at 03:13:18PM +0000, Simon Peyton-Jones wrote:
> 
> Incidentally when will ghc-devs go live?

I don't think there's any urgency to the changeover, so I think I'll
leave it until January, when I'll have time to fix any problems that
might arise.

Thanks
Ian
David Terei | 20 Dec 01:34 2012
Picon

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 <simonpj <at> microsoft.com> 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: cvs-ghc-bounces <at> haskell.org [mailto:cvs-ghc-bounces <at> haskell.org]
> | On Behalf Of David Terei
> | Sent: 12 December 2012 23:14
> | To: Ben Lippmeier
> | Cc: Ian Lynagh; cvs-ghc <at> 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 <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.
> | >
> | > Ben.
> | >
> | >
> | > _______________________________________________
> | > Cvs-ghc mailing list
> | > Cvs-ghc <at> haskell.org
> | > http://www.haskell.org/mailman/listinfo/cvs-ghc
> |
> | _______________________________________________
> | Cvs-ghc mailing list
> | Cvs-ghc <at> haskell.org
> | http://www.haskell.org/mailman/listinfo/cvs-ghc
Ian Lynagh | 6 Dec 18:21 2012

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

On Thu, Dec 06, 2012 at 09:56:55PM +1100, Ben Lippmeier wrote:
> 
> I suppose I'm the default owner of the register allocators and non-LLVM native code generators.

Great, thanks!

By the way, if you feel like doing some hacking this holiday season,
then you might be interested in
    http://hackage.haskell.org/trac/ghc/ticket/7063

Thanks
Ian
Ben Lippmeier | 7 Dec 01:44 2012
Picon

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


On 07/12/2012, at 4:21 , Ian Lynagh wrote:

> On Thu, Dec 06, 2012 at 09:56:55PM +1100, Ben Lippmeier wrote:
>> 
>> I suppose I'm the default owner of the register allocators and non-LLVM native code generators.
> 
> Great, thanks!
> 
> By the way, if you feel like doing some hacking this holiday season,
> then you might be interested in
>    http://hackage.haskell.org/trac/ghc/ticket/7063

Ah, holidays. Finally I'll have time to get some work done... :-)

Ben.

Gmane