Fwd: ghc-7.6 branch

[Ian Lynagh]

Hi Johan,

On Wed, Jun 27, 2012 at 03:06:39PM -0700, Johan Tibell wrote:
> 
> 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?

You didn't give a clear answer to my question. Am I right in thinking
that your answer would be "Yes, the GHC release should be delayed
indefinitely"?

(or at least, for long enough for the maintainer to be declared MIA)

> Again, note that GHC is no different from any other package here.
>
> 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.)

This is actually the main reason that the situation between GHC and the
libraries it uses is different to most other packages, both within
Haskell and without:

It is true that ghc depends on (for example) containers; but containers
also depends on base, and base/ghc are so intertwined that they are
essentially the same package (at least, I don't think you're suggesting
that we should make separate base and ghc releases).

That is what I mean by them being part of the same system.

For example, I recently removed the 'catch' export from Prelude, and
this required corresponding changes in Cabal, Win32 and haskeline. It's
not possible to make the change in the base library without making the
corresponding changes, or the GHC build would break, and there's no
reason the maintainers of the other packages would make the change if I
didn't ask them to.

A more mundane example is library dependencies. If we make a change in
filepath that requires bumping its major version, then we need libraries
such as Cabal to relax their dependency on filepath or, again, the GHC
build would break.

> Has maintainer's not being responsive been a problem for GHC in the
> past?

Yes. Some of the upstreams respond so fast that it makes my head spin,
while others often either don't respond or continually promise to get to
things soon. (again, these are good, well-meaning people, who do a lot
for the community).

> I believe this is the first time I've seen an email of this kind
> from GHC HQ.

Generally these mails are all directly to maintainers. They're generally
longer than this, but in essence it normally goes something like
    mail 1: "Could you take a look at this patch please?"
    mail 2: "Did you have a minute to look at that patch?"
    mail 3: "I think the patch is good. Would it help if I pushed it for you?"
    mail 4: "This is blocking other things, so I'd like to push it.
             Please let me know within a week if you object"
(there may be multiple mail 2s, and mail 3 sometimes gets an
affirmative response).

Once this has happened a few times, we tend to suggest switching to a
system where we just push by default, without the need for the mails and
the delay (in fact, more-or-less what Gershom suggested).


Thanks
Ian