Sysadmin Load Reduction: Code Related Services

[Albert Astals Cid]

El dissabte, 9 de novembre de 2019, a les 21:52:13 CET, Ben Cooksley va escriure:
> On Sun, Nov 10, 2019 at 8:43 AM Albert Astals Cid <aacid at kde.org> wrote:
> >
> > El dissabte, 9 de novembre de 2019, a les 18:47:57 CET, Ben Cooksley va escriure:
> > > 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?
> >
> > Over to what?
> 
> To using the YAML files within sysadmin/repo-metadata, which is what
> the legacy kde_projects.xml file is generated from currently.

Well, someone has to change the code that parses the xml to code that gets stuff from git and parses yaml, it's not hard, but has to be done.

> (Originally the kde_projects.xml file was generated from the
> Redmine/Chiliproject database - those YAML files just replaced it)

Yes i know :)

Cheers,
  Albert

> 
> >
> > Cheers,
> >   Albert
> >
> >
> 
> Thanks,
> Ben
>