Re: git: 0882d238e9b4 - main - Mk/bsd.sites.mk: Update GENTOO entries
- In reply to: Daniel Engberg : "Re: git: 0882d238e9b4 - main - Mk/bsd.sites.mk: Update GENTOO entries"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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