Le 31/03/2016 12:07, [email protected] a écrit :
Message: 8
Date: Thu, 31 Mar 2016 12:06:50 +0200
From: Luigi Toscano<[email protected]>
To:[email protected]
Cc:[email protected], KDE Sysadmin Help Desk<[email protected]>
Subject: Re: [kde-community] Our new project metadata system
Message-ID:<[email protected]>
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
_______________________________________________
kde-community mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-community
