Can't push to haddock

Simon Peyton Jones simonpj at
Tue Dec 19 10:17:33 UTC 2017

Dominance does not mean best nor fit for purpose.

I could not agree more.  Dominance leads to familiarity, and that /is/ valuable.  And dominance suggests that it is fit for purpose for a large group.   But the question is: what is fit for our purposes?

I think that is all that Herbert was getting at, and it’s the right question.   I’m making no assumptions about the answer, just saying that we should have no built-in bias (for or against) cloud solutions.

(And perhaps you are right to question my suggestion that a cloud repo is more reliable than a home-grown one.  I have no data.)


From: Phyx [mailto:lonetiger at]
Sent: 19 December 2017 10:08
To: Simon Peyton Jones <simonpj at>
Cc: Herbert Valerio Riedel <hvriedel at>; Sven Panne <svenpanne at>; ghc-devs at Devs <ghc-devs at>
Subject: Re: Can't push to haddock

On Tue, Dec 19, 2017, 09:48 Simon Peyton Jones via ghc-devs <ghc-devs at<mailto:ghc-devs at>> wrote:
It seems to me that there is some hostility towards GitHub in GHC HQ, but I don't really understand why. GitHub serves other similar projects quite well, e.g. Rust, and I can't see why we should be special.
Speaking for myself, I have no hostility towards GitHub, and there is no GHC-HQ bias against it that I know of.  If it serves the purpose better, we should use it.   Indeed that’s why I asked my original question.  I agree with your point that data may actually be safer in GitHub than in our own repo.   (And there is nothing to stop a belt-and-braces mirror backup system.)

These are just a few of the times github has been down in 2017<> compared to<><>

Other third parties such as<> have suffered catastrophic data failures and by the very virtue of them being free means they don't owe you anything.

I have nothing against github for small projects. I have nothing but hate for it for large ones. And I don't see that changing any time soon as everything they do seems to be half baked and the bare minimum
The issue is: does GitHub serve the purpose better?<> have frequently debated this multi-dimensional question.  And we should continue to do so: the answers may change over time (GitHub’s facilities are not static; and its increasing dominance is itself a cultural familiarity factor that simply was not the case five years ago).

As is often the case in computing history. Dominance does not mean best nor fit for purpose. Supposedly switching to these cloud based CIs were suppose to solve all our issues. And to this day none of them are working not withstanding the massive amount of effort wasted to get them to work.


From: Sven Panne [mailto:svenpanne at<mailto:svenpanne at>]
Sent: 19 December 2017 09:30
To: Herbert Valerio Riedel <hvriedel at<mailto:hvriedel at>>
Cc: Simon Peyton Jones <simonpj at<mailto:simonpj at>>; ghc-devs at<mailto:ghc-devs at> Devs <ghc-devs at<mailto:ghc-devs at>>

Subject: Re: Can't push to haddock

2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel <hvriedel at<mailto:hvriedel at>>:
We'd need mirroring anyway, as we want to keep control over our
infrastructure and not have to trust a 3rd party infrastructure to
safely handle our family jewels: GHC's source tree.

I think this is a question of perspective: Having the master repository on GitHub doesn't mean you are in immediate danger or lose your "family jewels". IMHO it's quite the contrary: I'm e.g. sure that in case that something goes wrong with GitHub, there is far more manpower behind it to fix that than for any self-hosted repository. And you can of course have some mirror of your GitHub repo in case of e.g. an earthquake/meteor/... in the San Francisco area... ;-)

It seems to me that there is some hostility towards GitHub in GHC HQ, but I don't really understand why. GitHub serves other similar projects quite well, e.g. Rust, and I can't see why we should be special.

Also, catching bad commits "a bit later" is just asking for trouble --
by the time they're caught the git repos have already lost their
invariant and its a big mess to recover;

This is by no means different than saying: "I want to run 'validate' in the commit hook, otherwise it's a big mess." We don't do this for obvious reasons, and what is the "big mess" if there is some incorrect submodule reference for a short time span? How is that different from somebody introducing e.g. a subtle compiler bug in a commit?

the invariant I devised and
whose validation I implemented 4 years ago has served us pretty well,
and has ensured that we never glitched into incorrectness; I'm also not
sure why it's being suggested to switch to a less principled and more
fragile scheme now. [...]

Because the whole repository structure is overly complicated and simply hosting everything on GitHub would simplify things. Again: I'm well aware that there are tradeoffs involved, but I would really appreciate simplifications. I have the impression that the entry barrier to GHC development has become larger and larger over the years, partly because of very non-standard tooling, partly because of the increasingly arcane repository organization. There are reasons that other projects like Rust attract far more developers... :-/

ghc-devs mailing list
ghc-devs at<mailto:ghc-devs at><>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list