[gentoo-dev] Sunsetting md5-cache mirroring for third party overlays: what to keep?

[gentoo-dev] Sunsetting md5-cache mirroring for third party overlays: what to keep?

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

Hello,

Per my previous announcements, we'll be sunsetting support for mirroring
and generating md5-cache for the vast majority of third party
repositories [1].  Given that the script is barely working anyway
nowadays, I'm just planning to stub out the bits responsible for
updating the repository list and just hardwire a bunch of hand-picked
repositories.

Which brings the question: which repositories should we mirror?  My
current thinking is to mirror the few major official or semi-official
repositories:

  gentoo, guru, kde, pentoo, science

Another potential candidates include R_Overlay and haskell -- though I'm
not sure about these since the former is autogenerated, and the latter
seems to be almost exclusively maintained by users.  I've also skipped
emacs, for the very simple reason that it's small, so md5-cache makes
little difference.  But I'm open to discussing these.

So, do you think that there are any other repositories we should be
mirroring?

Just to be clear, it means the mirrors with md5-cache on gentoo-mirror
GH org (I'm also thinking of repo/sync/ namespace in git.g.o for all of
them).  We will add the mirror entries to repositories.xml for default
syncing.  The remaining repos will be removed from the gentoo-mirror
namespace, so that users still using the entries from the old index get
a clear 404 and know they need to readd them.  This also means they'll
stop getting pkgcheck reports.

[1] https://github.com/gentoo-mirror/

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: [gentoo-dev] Sunsetting md5-cache mirroring for third party overlays: what to keep?

[Sam James]

Michał Górny <mgorny@gentoo.org> writes:

> Hello,
>
> Per my previous announcements, we'll be sunsetting support for mirroring
> and generating md5-cache for the vast majority of third party
> repositories [1].  Given that the script is barely working anyway
> nowadays, I'm just planning to stub out the bits responsible for
> updating the repository list and just hardwire a bunch of hand-picked
> repositories.

+1. Thanks for handling the dismantling. It's a source of problems and
not a good use of our time to keep babysitting issues with it.

>
> Which brings the question: which repositories should we mirror?  My
> current thinking is to mirror the few major official or semi-official
> repositories:
>
>   gentoo, guru, kde, pentoo, science


Please don't do pentoo. I don't mean this in a derogatory way, but the
standards of the repository aren't really what we want and I expect we'd
keep getting QA failures -- whereas these days, guru/kde/science are all
pretty well-maintained.

Having it mirrored will be a sign of an endorsement.

>
> Another potential candidates include R_Overlay and haskell -- though I'm
> not sure about these since the former is autogenerated, and the latter
> seems to be almost exclusively maintained by users.  I've also skipped
> emacs, for the very simple reason that it's small, so md5-cache makes
> little difference.  But I'm open to discussing these.

I wouldn't bother unless someone from those speaks up, I guess.

Haskell *might* be worth it because of the huge numbers of ebuilds.

>
> So, do you think that there are any other repositories we should be
> mirroring?
>
> Just to be clear, it means the mirrors with md5-cache on gentoo-mirror
> GH org (I'm also thinking of repo/sync/ namespace in git.g.o for all of
> them).  We will add the mirror entries to repositories.xml for default
> syncing.  The remaining repos will be removed from the gentoo-mirror
> namespace, so that users still using the entries from the old index get
> a clear 404 and know they need to readd them.  This also means they'll
> stop getting pkgcheck reports.

I still think we should consider injecting a news item per-repository to
blunt the pain for users, because we can inject the new sync URL. But
it's also not ever going to be enough for everyone because we'd have to
maintain the repos for long enough for them to propagate.

So, maybe in lieu of a time machine, we shouldn't bother, and just try
to make the ::gentoo news item as good as possible. I guess it won't be
too bad.

>
> [1] https://github.com/gentoo-mirror/

sam