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.)
The issue is: does GitHub serve the purpose better? We 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). Simon From: Sven Panne [mailto:svenpa...@gmail.com] Sent: 19 December 2017 09:30 To: Herbert Valerio Riedel <hvrie...@gmail.com> Cc: Simon Peyton Jones <simo...@microsoft.com>; ghc-devs@haskell.org Devs <ghc-devs@haskell.org> Subject: Re: Can't push to haddock 2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel <hvrie...@gmail.com<mailto:hvrie...@gmail.com>>: 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... :-/ </GrumpyMode>
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
