<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Hi Bill,<br></div><div><br></div><div>Thank you for your extensive response. I fully agree with everything said.<br></div><div><br></div><div>Reflecting on my request: It will not be a problem for me to share more information and become a trusted member in the long run. Setting up and sharing a multiple times per hour sync schedule is OK. A secondary way of contacting me (by phone or additional address) is no problem. I am a private person donating to the Arch(based) community by providing a mirror server. Not an organization or business.<br></div><div><br></div><div>With your permission I will continue syncing once an hour of rsync://repo.parabola.nu:875/repos/ for now and will follow everything happening including signing up for the future mirror mailing-list. If it's not OK to continue syncing because of the load, I will halt.<br></div><div><br></div><div>Would it be possible to provide my additional and private contact details to someone directly?<br></div><div><br></div><div>Best,<br></div><div><br></div><div>Eric<br></div><div><br></div><div>On Tue, Feb 23, 2021, at 9:25 AM, bill-auger wrote:<br></div><blockquote type="cite" id="qt" style=""><div>if the task were only to add a new mirror, that is quite easy to<br></div><div>do, but it is not a high priority - the mirror network is<br></div><div>healthier than ever now - in fact, it is becoming problematic to<br></div><div>add new mirrors; because the number of mirrors has almost<br></div><div>doubled in the past few years, and each new one adds load onto<br></div><div>the repo server, which is already over-loaded - we have been<br></div><div>working out plan to split the mirrors into tiers - that will<br></div><div>take some time and effort to accomplish though<br></div><div><br></div><div>that was not to say that we do not want any more mirrors - it is<br></div><div>always good to grow the mirror network; but there is no urgency<br></div><div>to that either - in fact, we hope that mirrors are dedicated for<br></div><div>the long-term; so some initial delay is prudent - as a point of<br></div><div>reference, the last two new mirrors did not get added to the<br></div><div>mirrorlist until a month or two after they requested - it is not<br></div><div>unreasonable, for example, to expect that someone may request to<br></div><div>join the mirror network and then shut down a month later -<br></div><div>patience is a virtue, as they say<br></div><div><br></div><div>as this thread subject suggests though, this could be one of the<br></div><div>tier 1 mirrors; and those entail significantly more<br></div><div>responsibility, and so deserve more scrutiny - there are some<br></div><div>logistics to work out first, in order to avoid adding more load<br></div><div>onto the repo server - that is the reason why i did not respond<br></div><div>immediately<br></div><div><br></div><div>the first step is to create a new mailing list dedicated to<br></div><div>mirrors - some of the current mirror operators have suggested<br></div><div>one, so there could be a low-volume channel, for only important<br></div><div>communication among the mirror operators, rather than expecting<br></div><div>everyone to subscribe to the 'dev' list<br></div><div><br></div><div>next, i have an email prepared to send out to all the mirrors<br></div><div>operators, asking some to be on tier 1 and stick to a rigid and<br></div><div>rapid sync schedule, (eg: 3-4 times per hour), and for the<br></div><div>others to start synchronizing with one of the tier 1 mirrors,<br></div><div>and also increasing their rate closer to once per hour - some of<br></div><div>them sync only once or twice per day now, while others sync<br></div><div>every 10 minutes, and yet others sync erratically - overall, it<br></div><div>should be a nice improvement for user-experience, to normalize<br></div><div>the sync rates across mirrors<br></div><div><br></div><div>regarding this new mirror, some of requested information was not<br></div><div>supplied - the wiki article requests that the introduction email<br></div><div>should include the name of the responsible party or organization<br></div><div>which operates the service, a secondary contact, and the precise<br></div><div>sync schedule - those are currently not essential, because all<br></div><div>mirrors are effectively tier 2 currently; but that information<br></div><div>will be essential for tier 1 mirrors<br></div><div><br></div><div>tier 1 mirrors will effectively be critical infrastructure; and<br></div><div>tier 1 mirror operators are effectively trusted team members -<br></div><div>not "trusted" as a matter of security (signatures accomplish<br></div><div>that), but as a matter of reliability - a significant proportion<br></div><div>of the mirror network will be dependent on their respective tier<br></div><div>1 mirrors; so there should be more than one possible way to<br></div><div>contact the operators in case of problems - if we only have a<br></div><div>single email address for an anonymous person, and especially<br></div><div>with that email is handled by the same host as the mirror, that<br></div><div>amounts to a single point of failure for a significant<br></div><div>proportion of the mirror network - ideally, we would also like<br></div><div>to have a GPG key for each tier 1 operator; and we do have one<br></div><div>for all of the current candidates<br></div><div>_______________________________________________<br></div><div>Dev mailing list<br></div><div><a href="mailto:Dev@lists.parabola.nu">Dev@lists.parabola.nu</a><br></div><div><a href="https://lists.parabola.nu/mailman/listinfo/dev">https://lists.parabola.nu/mailman/listinfo/dev</a><br></div><div><br></div></blockquote><div><br></div></body></html>