Sysadmin Load Reduction: Code Related Services

[Luigi Toscano]

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.

> 
> 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.
- 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?

-- 
Luigi