[kde-community] Our new project metadata system

Luigi Toscano luigi.toscano at tiscali.it
Thu Mar 31 12:43:55 BST 2016


On Thursday 31 of March 2016 17:10:13 Boudhayan Gupta wrote:
> 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.

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



More information about the kde-community mailing list