Let me repeat two desiderata from the beginning of the process, that
this fails to accommodate:

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

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.

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Tuesday, August 04, 2020 2:13 AM
>
> Summary of the discussion in the last thread:
>
> - No prior art found in other languages.
>
> - Publishing registries in a series of periodically finalized SRFIs,
> keeping a draft open for new submissions, is controversial.

Where controversial is basically "unworkable", plus goes in the
complete opposite direction of the above desires.

> - Relying on Git is controversial since Git hosting is seen as less
> permanent than the SRFI document stash itself.

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."

A Schemerepository page off of http://srfi.schemers.org/, which we
have much more control over, 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).

> - Using fancier software was considered too complicated.
>
> In an attempt to minimize effort and controversy and stick to
> established stuff, I'd like to suggest that we simply make a "registry"
> subdirectory in the
> <https://github.com/scheme-requests-for-implementation/srfi-common> Git
> repo and put some S-expression files there:

This is one of the most tightly controlled artifacts in all of the SRFI
process, is it not?  See above desires.

> - 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.

> - srfi-common is a particularly important repo since it has the whole
> SRFI website and metadata for all SRFIs, so we are unlikely to lose it.

See above, this also makes it the least desired repo to use for a fast
and loose lightweight process for the envisioned registry.

> - We can have a Scheme script that turns the registry into HTML page(s)
> published on the SRFI website. Arthur regenerates the website from
> srfi-common whenever a SRFI's status is updated, so hooking the registry
> generator into that update cycle would be easiest way to ensure the web
> copy of the registry stays updated.

Or hook it into a lightweight process for additions and changes.

> - 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.

> What do you think?

Bleah.  But I'm grumpy from not getting enough sleep so far tonight.

- Harold