There's only one "gnome" mirror listed in profiles/thirdpartymirrors, and it's the official upstream: $ grep gnome profiles/thirdpartymirrors gnome https://download.gnome.org/ It would be a small improvement to inline it (https://devmanual.gentoo.org/ebuild-writing/variables/index.html#third-party-mirrors), and after making the same change in a few ebuilds we would be able to eliminate the mirror entry entirely (which saves us from having to curate it by hand).
I don't see any improvements in doing so, only potential drawbacks for the future and just churn. How is this change an improvement?
They are only minor improvements: 1. The indirection is pointless. There's only one entry in the mirror list, and it's the official upstream URL (that itself directs you to a mirror). Resolving mirror:// is just an extra step and makes copy/paste harder. 2. Gnome's use of thirdpartymirrors isn't really what it was intended for (the devmanual lists the two valid use cases). We mirror every distfile onto Gentoo infrastructure anyway, so there is only a benefit to having an upstream mirror list when the package has RESTRICT=mirror. 3. The thirdpartymirror file needs to be maintained by hand and checked for dead mirrors, invalid SSLs, changed DNS, etc. There's a lot of junk in there and removing the gnome mirror would decrease the amount of work involved. So, it's housekeeping. But I don't think there are any drawbacks.
1. We can't predict the future. It might grow multiple addresses again, e.g. growing per-continent download URL while retiring the global one, because geolocation round robin software used falls over and is ditched. Or we need to temporarily list a few individual upstream mirrors ourselves as well, because their global rotation stops working for a couple of weeks - otherwise our mirrors aren't getting any of the new goodies at all. 2. I suggest you look into getting other useful use cases into the devmanual. There is no burden of maintaining it. 3. There is no maintenance needed on the gnome entry unless we notice that the upstream rotation has temporarily stopped functioning. Note that gnome.org.eclass is not the only consumer of this mirror entry in the tree, otherwise the only problem moving it just to gnome.org.eclass would be a huge metadata cache update when it needs to be touched, plus having to reintroduce the mirror again when one of the potential future problems noted under 1. actually materializes.
Ok, I don't want to argue about it because I've already far exceeded my allotted zero hours of maintenance.
No worries. To me the easy way to workaround an upstream bouncer temporarily breaking is the real killer feature of this mirror:// entry, given that otherwise that particular upstream bouncer is guaranteed stable. Some other single-entry mirror entries might have other benefits.
