[kde-community] Our new project metadata system
Olivier Churlaud
olivier at churlaud.com
Thu Mar 31 11:31:39 BST 2016
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
Cheers,
Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20160331/9d88ccfa/attachment.htm>
More information about the kde-community
mailing list