[arch-mirrors] [Announcement] Restructuring the arch-mirrors list
Luchesar V. ILIEV
luchesar at kerberia.net
Wed Feb 3 22:00:09 UTC 2016
On 03/02/16 21:39, Florian Pritz wrote:
> I'd also consider making the discussion list entirely open for posting
> from anyone, but this would not be in line with all our other lists so
> it would require some more discussion across all lists first. I dislike
> the idea of having different policies between lists so if I did this it
> should be for all lists.
I'm afraid I didn't understand that "open for posting from anyone": you
mean also open for non-subscribers? Because I think most/all discussion
lists are already open for posting for anyone who's subscribed, right?
> As for the mirror-admin-to-AL-admin case I think it's probably best if I
> publish the direct admin email I gave you. I'm unsure as to why you
> think this is mixed with the discussion list. The discussion list is
> really just intended for discussion where the sender wants outside
> opinions, not for mail that is only meant for Arch Linux staff. I'm not
> sure if anyone else is really interested in such discussion though or if
> all traffic should be directly with the mirro. Feedback welcome!
I agree that a simple e-mail address to contact the AL staff is more
than enough. And if it's something that should be discussed in public,
that's what the general discussions list is about, after all.
>> Could you explain where you see the advantage of having mirror admins
>> use a mailing list interface, with subscriptions, configuration changes,
>> and possible moderation/filtering/acknowledgement issues (compared to a
>> plain mail address that is forwarded to AL admins)?
> If mirror admins send their mail to a list we don't have to intervene
> and thus users get their information quicker and we don't need
> additional manpower. I'm currently taking care of mirrors on my own and
> the work load is really minimal. This might change if I start
> forwardings mails.
As a person who has managed such forwarding aliases, I totally agree
that a mailing list is a much more convenient and foolproof solution.
And for me this is true even as a subscriber. It isn't more convenient
at all when you have to write an e-mail just to update that address of
yours in the list... and then you realize that you've sent the wrong
address, and there goes another mail, and then the alias admin actually
screws it all and then two dozens of people suddenly pop up several
months later wondering why haven't they received any mail recently. ;)
> That being said I am not entirely happy with the current setup where
> users get a list of all direct mirror URLs and we can not control which
> ones they use. I believe it makes it really difficult for new mirrors to
> start being used and it is also practically impossible to properly
> balance traffic according to mirror bandwidth. I haven't thought about
> how this could be done better though because I don't really have the
> time to work on this issue at the moment.
I don't have much experience with this, but a DNS pool akin to the NTP
or PGP keyserver ones is the first thing that comes to mind. And just
like NTP, for example, there could be several layers of pools, based on
location: a "world" one, per-continent ones, perhaps even per-country.
I'm not really sure however how easy would it be to also prioritize the
mirrors in a pool based on their bandwidth. Or should we also account
for the other parameters, like latency, which can be pretty important,
or https availability, or delay from master...
In the end, I'm not even sure if that would be really necessary. Before
setting up our mirror, I've regularly used Reflector , which does the
job of choosing the best mirror quite well -- and based on what the user
considers most important. Not sure if it allowed prioritizing based on
latency, for example, but I guess there are also other tools like it
around that could be even better. Such tools have the strong advantage
over a DNS pool that the _real_ performance of the mirror with respect
_also_ to the user's location is taken into account.
Long story short: I wouldn't consider this to be much of an issue.
> Considering the points above, I'm not even sure if we need downtime
> notifications for users. When I took over as the Arch Linux mirror
> admin, I just noticed that some mirror admins send downtime notification
> to this list (most don't) and I didn't think about it. Any feedback by
> users that read such notification is welcome.
>From my standpoint as also being a user, I agree that the notifications
are not strictly necessarily, however:
1) I still would be happy to know if my preferred mirror (which happens
to be close by, is fast, etc.) is down for just a couple of hours, or if
it's something that's going to take awhile, or even if the mirror is
actually being retired completely, and
2) In the end, if the mirror admins _do_ want to notify their users in
some way, such mailing list is practically the only possible one. And I
can imagine rather more important notifications needing to be sent to
the users. Just think about a mirror that has been hacked and malicious
files have been uploaded to it. Of course, there are checksums and all,
but this is still something that is better communicated to the users for
various reasons, and the faster the better, rather than notifying AL
staff and hoping they can react quickly enough... Not to mention that
the AL staff would also then have the problem of identifying the
interested users -- if there isn't an announce@ list, that is. 
Well, hope this wasn't excessively TL;DR. ;)
C.lab, University of Plovdiv
 That was probably not the best example, as such an incident might
even need to be announced on the AL website, but I'm sure you can think
of other situations that might also require notifying the users of a
mirror, and which are more important than a downtime announcement.
More information about the arch-mirrors