On Sun, Nov 17, 2019 at 5:19 AM Carl Schwan <c...@carlschwan.eu> wrote: > > Hi all,
Hi Carl, > > Can the gitlab api be of useful in the future? > > e.g https://invent.kde.org/api/v4/groups/7 While for many purposes Gitlab's API wil be perfectly fine, it doesn't provide us with the i18n branch information which some users will require. > > Cheers, > Carl > Cheers, Ben > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Saturday, November 16, 2019 9:51 AM, Ben Cooksley <bcooks...@kde.org> > wrote: > > > On Sat, Nov 16, 2019 at 10:39 PM Albert Astals Cid aa...@kde.org wrote: > > > > > > El dissabte, 16 de novembre de 2019, a les 10:14:15 CET, Ben Cooksley va > > > escriure: > > > > > > > > On Sat, Nov 16, 2019 at 3:58 PM Alexander Potashev aspotas...@gmail.com > > > > wrote: > > > > > > > > > > пт, 15 нояб. 2019 г. в 22:05, Ben Cooksley bcooks...@kde.org: > > > > > > > > > > > > On Sat, Nov 16, 2019 at 3:27 AM Alexander Potashev > > > > > > aspotas...@gmail.com wrote: > > > > > > > > > > > > > > пт, 15 нояб. 2019 г. в 15:46, Harald Sitter sit...@kde.org: > > > > > > > > > > > > > > > > On Sat, Nov 9, 2019 at 11:37 PM Alexander Potashev > > > > > > > > aspotas...@gmail.com wrote: > > > > > > > > > > > > > > > > > > сб, 9 нояб. 2019 г. в 02:51, Ben Cooksley bcooks...@kde.org: > > > > > > > > > > > > > > > > > > > > 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) > > > > > > > > > > > > > > > > > > > Hi Ben, > > > > > > > > > I am developing a new version of the "opensrc" plugin for > > > > > > > > > Lokalize [1] > > > > > > > > > and it currently depends on kde_projects.xml. Of course I can > > > > > > > > > add new > > > > > > > > > code to scan the Git repo instead of just fetching > > > > > > > > > kde_projects.xml, > > > > > > > > > however it would be more complicated. > > > > > > > > > > > > > > > > > https://projects.kde.org/api/doc/ specifically deals with this > > > > > > > > problem > > > > > > > > by abstracting the repo away behind a micro service. > > > > > > > > > > > > > > > This looks like another view of the data available in > > > > > > > kde_projects.xml, however the API is very limited. For example I > > > > > > > can't > > > > > > > query repo descriptions using this API. Thus not helpful. > > > > > > > However if we were going to kill kde_projects.xml, are you sure > > > > > > > projects.kde.org/api/ would be still available and not shut down > > > > > > > as > > > > > > > well? > > > > > > > > > > > > > The API that Harald mentions is based off the YAML files, and is not > > > > > > reliant on the legacy kde_projects.xml file. > > > > > > > > > > > I can implement kde_projects.xml or a modernized version of it as part > > > > > of projects.kde.org/api/. Does this sound like a good idea? > > > > > We don't need to support the exact same XML format, so I would prefer > > > > > a JSON listing all projects with all their properties, at something > > > > > like GET https://projects.kde.org/api/v1/export or may be return all > > > > > project properties in GET https://projects.kde.org/api/v1/projects > > > > > > > > > I'll leave it to Harald to comment on whether he'd be happy having > > > > additional capabilities in the Projects Microservice API he maintains. > > > > (Harald, I assume it's only requirement is a copy of the > > > > sysadmin/repo-metadata repository locally, and it doesn't require the > > > > actual Git repositories?) > > > > We really should avoid continuing to keep legacy endpoints alive > > > > though (as it is just shifting the maintenance effort of porting away > > > > from it further down the road), especially for something that is going > > > > to end up on end user systems. > > > > > > > Wait, are you saying we shouldn't be using that endpoint to solve our > > > dependency on kde_projects.xml on scripty either? > > > I just asked Adrián to have a look at it, since it seemed easier than > > > having to worry about downloading and keeping an up to date copy of > > > another repo. > > > > > I was referring to the "implement kde_projects.xml" part of his email there. > > > > > The modern components of the projects.kde.org/api/ endpoint are of course > > fine. > > > > > > Cheers, > > > Albert > > > > > Cheers, > > Ben > > > > > > > On that note, should you be using QNetworkAccessManager, please ensure > > > > you forcibly and explicitly enable handling of redirects. > > > > > > > > > > -- > > > > > Alexander Potashev > > > > > > > > > Cheers, > > > > Ben >
