On Tue, Dec 19, 2017, 09:32 Sven Panne <svenpanne@gmail.com> wrote:
2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel <hvriedel@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.

Rust and Roslyn which also uses github both have essentially replicated phabricator features to github to make things manageable. People often ignore this on this off-handed remark that Rust uses github. This https://github.com/rust-lang-nursery/rust-forge/blob/master/infrastructure.md is part of the changes rust which has the backing of a major sponsor has to maintain to even start handling github. And I point out we have all of those just build into phabricator. 


And of all the tools I've used. Github has by far the worst interface to do code reviews. It's handling of rebases which will wipe all existing review comments when you push (collapsing them into oblivion) is very problematic. 

I'm not even sure they fixed the bug that pushing a later PR with the same branch name as an existing PR will permanently remove all review comments from the older PR. 

We're not special, we just don't want to trade a superior tool for a more popular but inferior one. 

Aside from being popular. Does github objectively have on redeeming feature?
 
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