[kde-community] Our new project metadata system

[Boudhayan Gupta]

Hi all,

On 31 March 2016 at 16:14, Jaroslaw Staniek <staniek at 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.toscano at 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.

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

For now, we use this data (held in sysadmin/repo-metadata) to generate
only kde_projects.xml and our JSON replacement for the same.

Unless I'e made a mistake, David Edmundson's script (in
http://marc.info/?l=kde-core-devel&m=138349411519937&w=2) seems to
generate AppData from the kde website. Said website is out of date and
does not contain info for newer apps (in fact, I couldn't find a page
for Spectacle). I see we've got the screenshots updated, so that's
awesome.

In any case, we'll be importing whatever data we can find from
kde.org/applications into repo-metadata. repo-metadata will become the
*only* place where metadata is kept; all other metafiles (XML, JSON,
AppData, the website) will be generated from there.

This ensures that metadata is never out of sync. The AppData, website,
JSON, and XML will always carry the same data.

>> Now, whether we like them or not, those metadata are already available and
>> going to stay. I don't think we want to duplicate again the same set of
>> data for the website.

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.

-- Boudhayan Gupta