> That Arthur not be a bottleneck/gatekeeper in the process of adding
> or updating the registry.

You're right, that precludes us from using srfi-common. Arthur has to
personally merge every PR made to that repo.

> Related, that the process of adding or updating the registry be
> "lightweight"; my preferred method, based on experience elsewhere, is
> a small pool of gatekeepers, and if any two agree with a proposed
> change, it's made to the registry.

Sounds good.

> Single branch git repositories are about the simplest and most
> distributable, replicable, and "backupatale" structured programming
> artifact that exists today, and git is not going to disappear or be
> replaced in the foreseeable future.  (If/when that happens, we would
> of course move with everyone else.)
>
> If one hosting provider nukes one of our repositories, which in the
> scenario you sketch out below would as likely happen to *all* of
> https://github.com/scheme-requests-for-implementation as it would to
> any of the repos contained in it ... I'm going to quote John here,
> "So get used to it."

I'm in favor of Git as the place where the ground truth is stored.

> A Schemerepository page off of http://srfi.schemers.org/, which we
> have much more control over,

If the plan was to not require Arthur's involvement, we should go with
registry.scheme.org. A web server is easy to arrange.

> can point to one or two canonical copies
> of the registry, and almost effortlessly change if we get betrayed
> by GitHub or whomever (certainly effortlessly compared to generally
> setting up on a new hosting provider if we must move).

Yes. Many Schemers are also in gitlab nowadays.

>> <https://github.com/scheme-requests-for-implementation/srfi-common> Git
>> repo
>
> This is one of the most tightly controlled artifacts in all of the SRFI
> process, is it not?  See above desires.

True.

>> - SRFI Git repos need to be archived anyway.
>
> I'm going to make my last call for using the rsync.net backup account
> I created for SRFI artifacts, like these repos, and the mailing list
> contents.  After October 1st when its year of initial funding
> expires, I'm going to let it go poof or use it for my own purposes.

Backing up there is fine.

>> - A dump of all SRFI data, "srfi.tgz" is published at
>> <https://srfi.schemers.org/srfi.tgz>. The registry source files could be
>> included in it.
>
> The only advantage this has it that there's already a process for
> doing it, and the total compressed data for the repository should be
> quite small by today's standards.  But presumably a parallel process
> that does this as well as HTML generation could be created.

Yes, e.g. a shell script that runs rsync :)