Can't push to haddock

[Sven Panne]

2017-12-19 9:50 GMT+01:00 Herbert Valerio Riedel <hvriedel at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171219/bbda396f/attachment.html>