[kde-community] Our new project metadata system

[Luigi Toscano]

On Thursday 31 of March 2016 12:31:39 Olivier Churlaud wrote:
> Le 31/03/2016 12:07, kde-community-request at kde.org a écrit :
> > Message: 8
> > Date: Thu, 31 Mar 2016 12:06:50 +0200
> > From: Luigi Toscano<luigi.toscano at tiscali.it>
> > To:kde-community at kde.org
> > Cc:kde-devel at kde.org, KDE Sysadmin Help Desk<sysadmin at kde.org>
> > Subject: Re: [kde-community] Our new project metadata system
> > Message-ID:<5718636.mFtRzCLg3p at whitebase.usersys.redhat.com>
> > Content-Type: text/plain; charset="us-ascii"
> > 
> > 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.
> > 
> > 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
> > 
> > And also, more recent:
> > https://mail.kde.org/pipermail/kde-community/2015q4/002132.html
> > 
> > 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.
> > 
> > I would say then to use them for the website, adding the missing files in
> > the process (most of applications are already covered).
> > 
> > Ciao
> > -- Luigi
> 
> Hi,
> 
> During the CERN Sprint we worked with Alex Merry on something similar,
> without knowing you were doing the same. Our idea is to have all
> metadata to generate a comprehensive api.kde.org.
> 
> You can see the notes here: https://notes.kde.org/p/apidox (please do
> not edit, even if I have a copy). I'm currently working on the the
> script that could generate the doxygen documentation from this, before
> releasing the proposition.
> 
> These "config.apidox"  files should just add infos that are not in
> "metadata.yaml". Maybe we should work together to have one global
> system, that can be used by everyone?
> 
> If it's not related to the topic, then sorry for the noise :S

I think it's different: you are talking about generating api.kde.org (and 
maybe, if I remember the past discussion, the entire techbase). This is about 
the project pages for kde.org and, more generally, the metadata for each 
application/library/git repository.

Ciao
-- 
Luigi