Fwd: ghc-7.6 branch
gershomb at gmail.com
Thu Jun 28 01:22:55 CEST 2012
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
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.
More information about the Glasgow-haskell-users