From nobody Thu Mar 30 03:50:14 2023 X-Original-To: dev-commits-ports-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pn8ZZ1g4Cz42M1c; Thu, 30 Mar 2023 03:50:14 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pn8ZZ17XQz3R8s; Thu, 30 Mar 2023 03:50:14 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680148214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XElDTqR8Zpa70fqZ0xOoWUwA0truYjZjClZf8ea/NYw=; b=d19tSdoyHMYOqIoQSyrmSZYOkog9YRjOJDFFosP3El+y32JAHuHGomd0FjQBYyC+merFWm kjqd3gcefyCTam+eyZmq4eXNixftdi6UJwAs+ty6ooAtv5BBwTZhnFfHNRoKtBedIlqBGe EJe3of1KsN2RS6WxaRq+4WK04kWG3pTePwn+4vlKn1gFXWarAX26fPUlO4ChYDQdiSfJqE DtnhQbDo4WE8JGBeXmazxfeZNwWsxZ9YgVGECG6RDgcidySpG8iUV7ZXeH2ZF1B3cQrGRI oYR+iKBG5CuY4b7o1Jhn5kg3lPk37y2RAqYze0hjv61FFtOpHBpHpoqKyYJU0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680148214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XElDTqR8Zpa70fqZ0xOoWUwA0truYjZjClZf8ea/NYw=; b=hzK5/dk8GU1YPIMenPpRj6pxnyW1ltEur4TbYbvC9YWcqtabqwEAgUQ4hUovr2BKR5zis6 PDqm5iEw90Xt8eyg1l6eCAKVpLrcCQL2tZQnNluA7v7/GPGvolVv0qxysHnlvikT0Ow3Js NSXiDDHuBhm+quQ8JQ67ch09guxEwrun1fWVAeUS3WeDZVUldMQ87Tmf0O9Ob6/jHVmmua aiFSkikO3HfHc3N6ijO9jIAP4jcAFzANSwQLjTGGgzOy+lBWBxd0ar6AGe8covAi0txEE1 46QBUx7My/33yuCxV/KrhxXQhKMEgAQwYlv/HUQNzs25+wakKEZLv3uP8mqHkQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1680148214; a=rsa-sha256; cv=none; b=X6OHZwXexi/9ZQ1dk4qcU345LOQmAYLeBHE3yS5CLoJYvYvJrayHYXS4q+ai2ysfa/s8Cz VLVBrpukvYqeL9MWg3CGlbhKRRZ+M5lU869wtdZdMyc62ds3SPaSVcVKXVPUcLvejZ/uce zjDPbO00drVm/8aVeQCl2vyJcxygvJTwbsfkadvOPIl8NsOov025IfOOXRBUp4028SB/O1 B1gfh6HFJlzBjIXF7fqZjGh4vSI2O5xAQUVQFNh5voV3rLSCISR80DNwwmuZpZvrCFDmGR E0vuzNIq4nc9lLpCrJBIABcdd0il6tu4PF8B2nwy3xurVIh8YKXiMZ+80O8Txg== Received: by freefall.freebsd.org (Postfix, from userid 1033) id 176696325; Thu, 30 Mar 2023 03:50:14 +0000 (UTC) Date: Thu, 30 Mar 2023 03:50:14 +0000 From: Alexey Dokuchaev To: Daniel Engberg Cc: ports-committers@freebsd.org, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org Subject: Re: git: 0882d238e9b4 - main - Mk/bsd.sites.mk: Update GENTOO entries Message-ID: References: <202303191808.32JI8pkK053370@gitrepo.freebsd.org> <5f1219b22121247109436ba2876fa0c8@FreeBSD.org> <3c5b33e230f1ae58dedc6e653f43e914@FreeBSD.org> List-Id: Commit messages for all branches of the ports repository List-Archive: https://lists.freebsd.org/archives/dev-commits-ports-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-ports-all@freebsd.org X-BeenThere: dev-commits-ports-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c5b33e230f1ae58dedc6e653f43e914@FreeBSD.org> X-ThisMailContainsUnwantedMimeParts: N 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