Re: git: 0882d238e9b4 - main - Mk/bsd.sites.mk: Update GENTOO entries

From: Alexey Dokuchaev <danfe_at_freebsd.org>
Date: Thu, 30 Mar 2023 03:50:14 UTC
On Wed, Mar 22, 2023 at 08:32:43AM +0100, Daniel Engberg wrote:
> On 2023-03-22 06:50, Alexey Dokuchaev wrote:
> > ...
> > Fair enough.  Mirrors do come and go and must be curated, but mixing
> > dead and "bad" ones together makes it hard to assess these changes in
> > retrospect.  Ideally we should be able to track any particular mirror
> > via commit logs, esp. because sometimes they are not totally gone, but
> > moved from rotation temporarily, change ISP, colocation, etc.
> 
> Ideally I agree however from what I've seen no other project does that
> outside of their own mirror pool and I think we can trust upstream in
> such cases. If we see degraded performance for a long period of time (as
> we all know hardware/Internet breaks sometimes) we can just adjust our
> "local" list and move on.

I think you've missed my point, let me rephrase: when changing mirror
list and writing commit log, please separate dead mirrors from "bad"
(slow, incomplete, etc.), that is, document exactly which mirrors are
dead and which are "bad".

> We still need to assume that a connection works as expected and as I
> mentioned earlier vast majority of ports only have a single host (apart
> from our distcaches) so this doesn't make any practical difference it
> just adds overhead.

I still don't see what overhead adding another mirror entails.

> >> I think we can safely say that if 8 hosts in different regions, ASNs
> >> etc. fails your host has more issues than the amount of mirrors we
> >> provide, in fact the vast majority of ports actually provides fewer
> >> mirrors than that including FreeBSD's infrastructure.
> > 
> > That's beyond my point, which is: more mirrors is better than less.
> > But oh well, I guess I could always put some extra MASTER_SITE_GENTOO
> > in my /etc/make.conf.
> 
> It makes no practical difference if a mirror list is somewhat well
> maintained/curated so I kindly disagree on that one but you can of
> course maintain forks locally if you so choose.

I've kept my patched Mk/bsd.sites.mk for years and it worked like a charm
with SVN, I wouldn't bother starting this discussion.  It is just now with
Git keeping local changes had become big nuisance because it cannot into
auto-merge, so once must stash her changes, update, then re-apply.

If anyone has custom "auto-merge" patch for Git that upstream won't take
for some reason, please share!  This is really driving me nuts. :(

./danfe