Hi, as mentioned in https://lists.centos.org/pipermail/centos-devel/2018-September/016949.html mirrorlist.centos.org has been updated to produce mirror lists for SIG content as well. Some centos-release-* packages have already been modified to use mirrorlist.centos.org instead of mirror.centos.org, but many still point to mirror.centos.org.
Most of mirror.centos.org hosts are also used for seeding the 600+ external mirrors we have. By directing some of their download traffic to external mirrors we can offer faster sync speeds for those external mirrors, and for people downloading individual rpms from mirror.centos.org. Second, most of those external mirrors offer faster download speeds to end users than what could be achieved by downloading from mirror.centos.org, so the users will benefit from this change as well. The better geographical coverage does not hurt either. mirror.centos.org nodes are donated servers, and it would be kind to the sponsors to use their bandwidth sparingly.
The .repo files should be modified so that the current baseurl line gets commented out and a mirrorlist entry gets added, like this:
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/$contentdir/$releasever/storage/$basearch/gluster-4...
Note that mirrorlist.c.o can automatically choose between main and altarch content based on the arch parameter. The repo names are constructed from the repository path by stripping away the architecture and changing any slashes to dashes: sclo/x86_64/rh -> sclo-rh, sclo/x86_64/sclo -> sclo-sclo, paas/x86_64/openshift-origin311 -> paas-openshift-origin311, storage/x86_64/gluster-5 -> storage-gluster-5 etc. You can use 'curl' to check what mirrorlist outputs for your repository.
New repos are added to mirrorlist.centos.org automatically once the repository hits mirror.centos.org. That script is currently run every three hours. I guess it could be run more frequently (it's fairly lightweight), but you should give the external mirrors a few hours to sync before announcing your release anyway.
You can either submit an update to your current centos-release-* file now, or wait until you need to create a new centos-release-* package for other reasons such as releasing softwarepackage-(version+1) which uses different paths. My recommendation would be to submit an update to your current centos-release-* package, so that you would not need to worry about this when you eventually need to publish a new one for other reasons. We released an updated centos-release package for CentOS AltArch before 7.6.1810 was released for this exact reason, ie. we didn't need to worry about this change at 7.6.1810 release time.
Other people (such as bstinson, arrfab and hughesjr) can probably help with creating and publishing an updated centos-release-* package, but the usual tagging procedure to extras will apply. The SIG Guide https://wiki.centos.org/SIGGuide should have all the needed details for this (if not, complain to bstinson). It is highly recommended to actually test your new centos-release-* package from buildlogs before you ask that package to be signed and pushed to extras.
The holiday season is fast approaching so (I) don't expect much activity regarding these changes in the following days. I'm hoping that the SIGs would take a look at this in early 2019, though. Thanks to those SIGs who have already made these changes to their centos-release-* packages!
If you have questions, feel free to ask either here or on #centos-devel. Thanks for your time!