Fwd: ghc-7.6 branch

[Johan Tibell]

Hi,

On Wed, Jun 27, 2012 at 12:53 PM, Ian Lynagh <igloo at earth.li> wrote:
> If a GHC release needs an unreleased change in one of the libraries, and
> the maintainer (for whatever reason) is not responding to e-mails,
> should the GHC release be held up indefinitely?

Again, note that GHC is no different from any other package here. If
the maintainer is not responsive a person depending on his/her package
can:

 1) Try to convince him/her to become responsive.
 2) Try to change the maintainer (this has happened for a few Hackage
libraries, with the previous maintainer's approval usually.)
 3) Drop the dependency.
 4) Fork the package.

This is how open source works outside GHC (including in different
community's.) I don't see a need for doing anything differently here.

Has maintainer's not being responsive been a problem for GHC in the
past? I believe this is the first time I've seen an email of this kind
from GHC HQ.

> If the answer is "no", then there are going to be times when we need to
> ship GHC with a version of a library that is not yet released. With the
> best will in the world, there are always going to be people who are
> swamped by real life, people on vacation, or even people who unbeknownst
> to us have died.

If people don't have time I'm sure they won't mind handing over
maintenance to GHC HQ. I don't think it's OK to say "if you're on
vacation and don't reply in X days we're making a release of your
package." Imagine if someone did that on Hackage: "I really needed
change X to your package to make my package work but since you didn't
reply to my email I made the change and released a new version of your
package."

> But all that is really tangential to the main issue: even if the answer
> to the above question is "no", that does not mean that we need to
> routinely release libraries maintained by active upstreams. If upstream
> is responsive, then we can discuss with them what code to use and what
> releases need to be made. The original e-mail was intended to be the
> first in that discussion. Perhaps we phrased it badly, or perhaps you
> have bad memories of previous mistakes or of previous systems of
> releasing, but all we were trying to do is to find out what code we
> should set up the new stable branch to use.

Phrasing aside, I think the problem is one of misunderstanding how the
process of managing dependencies ought to work (and how it works
elsewhere.) "We must release a new version of so-and-so lib because we
made such-and-such change" is wrong. Upstream changes (i.e. to GHC
deps) ought to happen before downstream releases of dependent code
(i.e. GHC.) The current system is only possible due to GHC shipping
libraries together with the compiler, several of it only uses
internally to boot!

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.

Cheers,
Johan