Fwd: ghc-7.6 branch

[Gershom Bazerman]

On 6/27/12 6:06 PM, Johan Tibell wrote:
> This is not a theoretical issue. We have had all of the following
> problems happen in the past due to the current process:
>
>   * patches never making it upstream
>   * releases of libraries without knowledge of the maintainer (who
> finds out by finding a new version of his/her package on Hackage.)
>   * packages being released by GHC never ending up on Hackage, causing
> build breakages for people who use older GHCs and can't install the
> packages as they aren't available on Hackage.
>
At the almost certain risk of stepping into a discussion I don't fully 
understand, let me step into a discussion I almost certainly don't fully 
understand :-)

It seems to me that all these issues could be solved by having a member 
of the GHC team an assistant co-maintainer on packages that GHC depends 
on, and acting as such in a responsible manner, and in addition, having 
all packages bundled with GHC releases drawn from hackage releases. This 
is to say, that ghc-originated patches necessarily get committed to the 
upstream repo, because they must be there to be released on hackage, 
that ghc-originated patches necessarily get released to hackage because 
they must be there for GHC releases to draw on them, and maintainers 
necessarily know what gets released to hackage because they communicate 
well with co-maintainers.

This is different than community ownership -- packages are still owned 
and maintained by individuals. However, by having a ghc assistant 
co-maintainer, there's a specified conduit for collaboration. This is 
also different from the current situation, because a co-maintainer may 
only work on issues for GHC release compatibility, but they are acting 
as someone with direct responsibility for the package and as part of the 
team that "owns" the package.

Problems of collaboration aren't magiced away by this sort of change of 
titles, of course, but when there are problems of communication and 
collaboration, they can now be understood as and treated as problems 
between primary and secondary package maintainers.

I hope this makes some semblance of sense.

Cheers,
Gershom