On Thursday 31 of March 2016 17:10:13 Boudhayan Gupta wrote: > Hi all, > > On 31 March 2016 at 16:14, Jaroslaw Staniek <stan...@kde.org> wrote: > > +1 for using wider accepted standards, whatever they are, and making life > > of distros easier too. > > Making life for distros easier is one of the primary goals for this, > > and apps.kde.org will fulfil that need, see below for more: > > On 31 March 2016 at 12:06, Luigi Toscano <luigi.tosc...@tiscali.it> wrote: > >> On Thursday 31 of March 2016 13:55:03 Boudhayan Gupta wrote: > >> > Hi all, > >> > > >> > Over the last few weekends we've been doing some spring-cleaning to > >> > our infrastructure. You may have noticed that we've killed off > >> > projects.kde.org, and we have new scripts that generate our > >> > kde_projects.xml without having to depend on ChiliProject now. We're > >> > also planning to deprecate kde_projects.xml itself, and to that effect > >> > we've started setting up a JSON/REST API at > >> > https://apps.kde.org/api/v1/. > >> > > >> > The same infrastructure that is used to generate data for our API and > >> > the XML file can be used to generate a HTML website with landing pages > >> > for our applications, and this is something we intend to do in the > >> > coming months as a replacement for the outdated kde.org/applications > >> > site. To achieve that, however, we're going to need some help from > >> > you. > >> > > >> > Our project metadata is currently held in the sysadmin/repo-metadata > >> > repository. We currently hold data about the project name, repository > >> > and a one-line description of each project. We would like maintainers > >> > and anyone who can help to provide us with three things for every > >> > project - a *description.md* file with a bigger description of each > >> > project that appears on the website, and for applications with a GUI, > >> > a *screenshot.png* file with a screenshot of the app and two icons (a > >> > 256 * 256 px icon.png and a 512 * 512px icon_2x.png). > >> > >> I don't think we need to do this; we have AppStream metadata. > > We do need to do this, because AppStream metadata will also eventually > be generated from this repo. I'll do an initial import of data from > d_ed's AppData XML files, for now.
Wait, no. The metadata there are outdated, the ones in project repositories have been updated _and_ translated in the meantime. > > >> Long time ago it was in fact discussed how to not duplicate the > >> information > >> between the json on the website and the AppStream metadata. There was > >> some > >> idea on how to generate one from the other. Check this old thread on > >> kde-core- > >> devel, from November 2013 ("Adopting AppData in KDE? > >> http://marc.info/?l=kde-core-devel&m=138348776618380&w=2 > >> http://marc.info/?l=kde-core-devel&m=138349411519937&w=2 > > The idea here is to hold all the metadata in one place in a format > which is easy for humans to manipulate, and from which we can generate > all other metafiles. AppStream metadata are already decentralized, and you don't want a sysadmin ticket for each change to one of them. Let's have them in the hands of each project manager. So I strongly disagree with moving from the current status. > > We're not duplicating anything. We're trying to trim down the number > of places where you can find metadata to *one* location, and then > generating everything else from there. So you consume the existing AppStream metadata from each project repository. As I said, they are well handled and translated. No need to import them in the centralized store. -- Luigi