On Sun, Nov 10, 2019 at 1:24 PM Albert Astals Cid <aa...@kde.org> wrote: > > El diumenge, 10 de novembre de 2019, a les 1:04:04 CET, Ben Cooksley va > escriure: > > On Sun, Nov 10, 2019 at 11:22 AM Albert Astals Cid <aa...@kde.org> wrote: > > > > > > 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 <aa...@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.tosc...@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. > > > > *nod* > > > > I do recall that at one point in our conversations that scripty only > > used the kde_projects.xml file as a check against it's own internal > > data. > > Yes and no, we have our i18n branch data hardcoded, but we don't have a list > of repos, so we need the list of repos from somewhere (and we use the branch > data from kde_projects.xml to compare it to our hardcoded one to see if > there's some mismatch). >
Thanks for confirming how that is used. > Cheers, > Albert > Cheers, Ben > > Has that since been changed? > > > > > > > > > (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, > > Ben > > > > > > > > > > > > > > > > > > > Cheers, > > > > > Albert > > > > > > > > > > > > > > > > > > Thanks, > > > > Ben > > > > > > > > > > > > > > > > > > > > > >
