Re: [gentoo-project] Call for agenda items - Council meeting 2021-04-11

[Rich Freeman]

On Fri, Apr 9, 2021 at 12:03 AM Alec Warner <antarus@g.o> wrote:
>
> For example on my box:
>  rsync takes about 5s for an up-to-date-check.
>  rsync takes about 1m for a daily-like sync (includes up-to-date
> check, incremental delivery, and GPG verification with WKD.)
>  rsync takes longer for a full sync, but I tend to use web-rsync for that task.
>  Github seems to have taken about 4s for an empty sync (e.g. up to date)
>  Github seems to have taken about 6s for a small sync (e.g. daily)
>  Github seems to have taken 20s for a full sync.

I think that type of storage and cache is going to matter a LOT here,
as does update frequency.  A hard drive is going to perform far worse
for rsync, but probably not all that differently for git.

The issue is that rsync has to walk the entire repository to figure
out what changed (the cost of which depends on IOPS and cache state).
Git has an index in the form of the commit linked list and also the
tree content hashes.

On the other hand, git by default stores a whole lot of history that
is either a pro or a con depending on your requirements.  If you're
syncing once every few months git by default probably ends up sending
a whole bunch of intermediate stuff you don't care about, while rsync
just jumps you to the present.  (Ie, if a package is revised 5 times
in six months, rsync gets you from v1 to v5, while git sends you v2-4
and the metadata that tells you not to use them (but they're still
there in case you want to check out those commits)).

So, I think any technical comparison needs to pay a lot of attention
to how the repo is used and synced, and how it is stored, and how
stale the cache is when it is synced.

Really though I think the hosting issue is the bigger concern.

> So two things here. One is that we should care about the social
> contract and I think bi-furcating the core parts of gentoo into free
> and non-free is a non-trivial change. If we move people to git syncing
> and github makes some changes, or goes away, or whatever...it's not
> like we have equivalent free setup; our git hosting is literally not
> up to the task of serving those users.

I think hosting diversity is the much larger issue here: we have a ton
of http/rsync mirrors, and there aren't really a lot of options for
git mirroring out there.

If we were using a single CDN vendor for http or rsync to run our
entire mirror network I'd have the same concerns there.  As you say,
if github changes their TOS/whatever we'd be up the creek.  If one of
our bazillion http mirrors told infra they can't host us anymore it
wouldn't be a big deal because we have a ton of mirrors and they're
largely independent.  If we were using CloudFlare as our sole http
provider and CloudFlare decided to change their TOS or something, then
again would be up the creek.

So, I'd suggest that if we wanted to consider git as a primary
recommended syncing system, the main focus should be on a diversity of
mirroring providers.  I think that whether they run FOSS is a
nice-to-have as in the end git itself is FOSS and the protocol is what
matters there.  Just as we don't require http mirrors to run coreboot
I don't think we should care all that much which git implementation
they're running.  However, a diversity of providers would matter more.

However, for those who do think that FOSS-only is critical I'd say the
diversity angle would solve that.  If you're going to have 50 git
mirroring providers, it seems very likely that some would be FOSS
top-to-bottom.  I'm guessing that at most 2% of our http mirrors are
FOSS top-to-bottom (including firmware), but just having so many
ensures that people who care about that can do so, and those who don't
mind if the http mirror runs IIS as long as it speaks http can use
whatever they want.

-- 
Rich