Hi,
On Wed, Jun 27, 2012 at 12:53 PM, Ian Lynagh
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