Le 31/03/2016 12:36, Luigi Toscano a écrit :
On Thursday 31 of March 2016 12:31:39 Olivier Churlaud wrote:
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
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
Yes, I understand this (and you remember well) but it still redundant
info: we need screenshots, logo, git-repo.. as well.
Maybe it's not needed for kde.org, but if it is, it would be inefficient
for the maintainer to maintain data in several metadata files.
It's just what I wanted to point out so that we work together if needed.
Cheers
Oliver
_______________________________________________
kde-community mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kde-community
