Sysadmin Load Reduction: Code Related Services

[Ben Cooksley]

On Sun, Nov 10, 2019 at 12:29 AM Luigi Toscano <luigi.toscano at tiscali.it> wrote:
>
> Ben Cooksley ha scritto:
> > Hi all,
> >
> > In the category of code related services, Sysadmin currently supports
> > a wide-ranging number of services (which makes sense given the nature
> > of the community). Some of these however may no longer be in use or
> > will be duplicative of other services following the transition to
> > Gitlab.
> >
> > In the category of duplicative, we have our two CGit instances at
> > cgit.kde.org and packaging.neon.kde.org. Prior to Gitlab, these were
> > justifiable as there was no other way of browsing scratch/clone
> > repositories over the web.
> >
> > With the migration to Gitlab however all repositories will become
> > browsable through it, meaning it no longer makes sense to offer two
> > browsers that provide the exact same information (with Gitlab having
> > greater capabilities). I'd therefore like to shut both of these down
> > once Code Hosting has transitioned to Gitlab.
>
> Luckily we tried to use commits.kde.org as generic redirect. Will the generic
> redirect commits.kde.org be updated to point to the proper repository? It may
> be complicated if the new structure contains the namespaces for each
> repository, but we need to keep it working.

The commits.kde.org redirector is intended to provide permanent links,
so yes it will be updated to redirect people to Gitlab instead once
the switch to Gitlab is completed.

>
> >
> > In the category of no longer in use, we have the compatibility
> > generator for the kde_projects.xml file. This was introduced when we
> > shutdown Redmine/Chiliproject and migrated to Phabricator, as a way of
> > keeping services that needed to discover a list of KDE Projects
> > functional.
> >
> > As we've since migrated to using YAML files within the
> > sysadmin/repo-metadata repository for both the CI System and
> > kdesrc-build (and with LXR using kdesrc-build to do it's code
> > checkouts) there shouldn't to my knowledge be anything still relying
> > on this (aside from perhaps scripty).>
> > I'd therefore like to shut this generator down as well, along with the
> > compaibility redirector running at projects.kde.org (given that it has
> > been some time since we were using that site, and many projects have
> > moved around in the virtual structure since then, making the redirects
> > it is able to offer useless)
>
> Two points:
> - scripty still uses the XML file and we may need some time to migrate.

I feared this may have been the case. What sort of timeline are we
looking at in terms of switching scripty over?

> - we may have a few links around which still points to projects.kde.org (for
> example, the "Consistency" goal listed a few of them), so we may need to go
> through all of them before doing that.
> Do we have measures that shows how much projects.kde.org is hit by services
> which are not scripty?

I've reviewed the logs for the past 24 hours and it would appear the
majority of the legitimate hits now are for the RSS/ATOM feeds that
Chiliproject used to offer and which have no corresponding replacement
(amazingly, these are still configured in people's feed readers).

After excluding bots and spiders, and people running automated tools
against old URL sets, very little in the way of hits remained.
The remainder are a very small proportion of hits from places such as
the Archlinux wiki, which we can likely request to be updated
(referencing Bluedevil in particular it would seem).

>
> --
> Luigi

Cheers,
Ben