Can't push to haddock

[Ben Gamari]

Sven Panne <svenpanne at gmail.com> writes:

> 2017-12-19 12:47 GMT+01:00 Phyx <lonetiger at gmail.com>:
>
>> Cool, then let's turn to media reports then such as
>> https://techcrunch.com/2017/07/31/github-goes-down-and-takes-developer-
>> productivity-with-it/ do you have one for git.haskell.org going down?
>
>
> Of course this question is a classic example of "the absence of evidence is
> not the evidence of absence" fallacy, but anyway:
>
> *
> https://www.reddit.com/r/haskell/comments/4gppm8/ann_hackagehaskellorg_is_down/
> * http://blog.haskell.org/post/4/outages_and_improvements.../
> * Searchs ghc-devs@ for posts regarding Phabricator updates, Server moves,
> problems with arc... (not exactly all downtimes, but in effect of the
> incidents are the same)
>
> I am not saying that the haskell.org infrastructure is bad, far from it,
> but it would be an illusion to think that it has a much higher effective
> uptime than GitHub. Furthermore: I don't think that the argument should
> revolve around uptime. We have a distributed version control system where
> people can happily work for an extended time span without *any* network at
> all, and the GHC source repository is not a financial application which
> would cause the loss of millions of dollars per minute if it's temporarily
> unavailable. The arguments should be about simplicity, ease of use, etc.
>
> Anyway, for my part the discussion is over, there *is* more or less open
> hostility towards GitHub/more standardized environments here. Is it an
> instance of the common "not invented here" syndrome or general mistrust in
> any kind of organization? I don't know... :-/

I'm not sure that it's either of these; rather I think GHC is simply a
large project with a rather distinct set of needs than most smaller FOSS
projects. It is not at all uncommon for large projects to have their own
infrastructure: LLVM, GCC, golang, GNOME, KDE, the Linux kernel,
blender, firefox, FreeBSD, and many others all use their own
infrastructure for code review, issue tracking, code hosting or all
three. We are quite far from being alone in this regard.

For what it's worth, I'm not necessarily opposed to moving hosting of
GHC's repositories to GitHub, GitLab or nearly any other hosting
solution assuming that a few things can be ensured:

 * Trac notifications continue to work

 * Commits containing bad submodule references don't make it into the tree
  
 * We have a means of controlling who can push to which branch namespaces

 * We don't need to manually synchronize contributor keys to/from Phabricator

Note that moving code review or issue tracking to GitHub is a much
different question and I think there are good reasons to be skeptical of
such proposals, especially in the case of the issue tracking.
Regardless, I suspect this is a discussion best had on the devops list.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171220/9bd04514/attachment.sig>