> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Friday, August 07, 2020 9:58 AM
>
> [ rsync.net ]
>
>> GitHub's competency in operations is quasi-infinitely better than
>> GitLab's (ask for details), I'd advise making any master repo be on
>> GitHub as things stand today.
>
> Details would be interesting. I don't have a preference on which host
> the master copy is on, but I couldn't as easily find free github->gitlab
> automatic push. Maybe it exists.

GitLab's worst incident I know of is when they lost customer data due
to every single backup they were using failing.  They simply didn't
bother to check if any of them were working, not even looking at how
much data was being stored in an S3 bucket.

There tend to be consequences for paying below market rates as they're
strongly reputed to do.  100% remote also takes management talent
that's generally not in evidence in our field.

One other reason to make it the master is that I'm pretty sure a
lot more people have GitHub accounts than GitLab ones, and if both,
use the former a lot more, if not all but exclusively.

> I turned off the issue tracker and wiki in GitHub. We should be
> disciplined about having discussions on the mailing list.

I've suggested that pull request discussions happen in the comments
on the pull request, and get scraped and sent as one digest to
the mailing list after resolution.  That way we can limit traffic
on the mailing list, by announcing when a pull request has been
made and providing a link, so those interested in the specific topic
can subscribe, and the rest aren't bothered.

> [ More on rsync.net. ]
>
> If we are to back up all the SRFI repos in one central place, that may
> require some creativity as it may hit GitHub's traffic limits if pulling
> 200+ repos consequently.

Not very much creativity, here's the script I used to backup in batch
to rsync.net all the SRFI repos:

#!/bin/bash
# -*- mode: sh; sh-basic-offset: 3; indent-tabs-mode: nil; -*-

for i in [ the numbers, 1 to 175 ]
do
  ssh.srfirsync.net "git clone git://github.com/scheme-requests-for-implementation/srfi-$i.git srfi/github/srfi-$i.git"
  sleep 30
done

Patience goes a long way.  Another approach is to add backup to the
workflow of publishing a new draft of an SRFI if that workflow is
rigorous enough.

- Harold