Re: [kde-community] Our new project metadata system

2016-04-02 Thread Boudhayan Gupta 
On 2 April 2016 at 15:39, Thomas Pfeiffer  wrote:
> On Freitag, 1. April 2016 10:37:46 CEST Richard Hughes wrote:
>> On 31 March 2016 at 12:43, Luigi Toscano  wrote:
>> > 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.
>> Agreed. You also want different screenshots and descriptions for
>> different branches of each project. Centralised storage of this was a
>> complete non-goal when designing AppStream for distros. If you want to
>> standardize where each appdata file is stored in the project (in
>> GNOME, it's sometimes ".", "data", "data/appdata" or "src") that might
>> be a worthy but difficult goal, but saying you can repopulate a
>> standards compliant AppData file from JSON and Markdown doesn't sound
>> very plausible at all.
>>
>> Also, like it or not, people are browsing and installing software
>> using software centers. I don't think people go looking at
>> https://www.kde.org/applications/ when trying to install a new game.
>> Quite literally, there is no "Install" button to be found on that
>> website.
>
> Actually, the "install button" is in the works, because AppStream links make
> that possible. This is actually important to allow people to directly link to
> an application when they are for example recommending it to a friend.
>
> Still, of course, software center applications will be the most common way to
> install applications.
>
> We just have to make sure that we have both high-quality web and software
> center presentation.

While we're at it, could the VDG cook up some templates we could use?

This will most probably be done by a GSoC student (whom I'll be
mentoring), so the work starts sometime in the middle of June.

-- Boudhayan
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Our new project metadata system

2016-04-02 Thread Richard Hughes 
On 31 March 2016 at 12:43, Luigi Toscano  wrote:
> 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.

Agreed. You also want different screenshots and descriptions for
different branches of each project. Centralised storage of this was a
complete non-goal when designing AppStream for distros. If you want to
standardize where each appdata file is stored in the project (in
GNOME, it's sometimes ".", "data", "data/appdata" or "src") that might
be a worthy but difficult goal, but saying you can repopulate a
standards compliant AppData file from JSON and Markdown doesn't sound
very plausible at all.

Also, like it or not, people are browsing and installing software
using software centers. I don't think people go looking at
https://www.kde.org/applications/ when trying to install a new game.
Quite literally, there is no "Install" button to be found on that
website.

Richard.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Our new project metadata system

2016-04-01 Thread Aleix Pol 
On Fri, Apr 1, 2016 at 3:13 PM, Boudhayan Gupta  wrote:
> On 1 April 2016 at 17:58, Thomas Pfeiffer  wrote:
>> On Freitag, 1. April 2016 21:54:10 CEST Ben Cooksley wrote:
>>
>>> Out of curiosity, how are the Appstream files accessed by tools such
>>> as the various app centers?
>>> I presume some kind of repository exists?
>>
>> Nope, actually distributions extract the appstream data from the source code
>> of each application and generate their own AppStream database.
>>
>>> If so, it may be worth pulling the information you need Boudhayan from
>>> such a repository ( although the indexing process will undoubtedly
>>> require either source code checkouts or compiled code, in which case
>>> we'll probably have to use what the CI system has and pick a branch
>>> group to represent - probably stable-kf5-qt5. More details on this
>>> would be nice )
>
> I was looking at the AppStream XML files and it has all the data I
> need, even the translations. I can use that.
>
> We could run a nightly job to pull in AppStream data from the repos
> and keep it in a place the apps website code can access. Keeping it in
> a standard place in the repo (say at the root) is probably a very good
> idea.
>
>> We could theoretically just tap into a distribution's AppStream database if
>> that makes our lives easier, or just reuse their code to extract the data and
>> create the database.
>
> Using distributions' databases mean we don't have control over the
> infra for our website. I don't think we can have that.

You don't need the distribution database, because they will add
information you don't need.

A way to get all the files is to look into
$PREFIX/share/appdata/*.appdata.xml. Maybe this can be extracted from
build.kde.org.

Aleix
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Our new project metadata system

2016-04-01 Thread Thomas Pfeiffer 
On Freitag, 1. April 2016 21:54:10 CEST Ben Cooksley wrote:

> Out of curiosity, how are the Appstream files accessed by tools such
> as the various app centers?
> I presume some kind of repository exists?

Nope, actually distributions extract the appstream data from the source code 
of each application and generate their own AppStream database. 
 
> If so, it may be worth pulling the information you need Boudhayan from
> such a repository ( although the indexing process will undoubtedly
> require either source code checkouts or compiled code, in which case
> we'll probably have to use what the CI system has and pick a branch
> group to represent - probably stable-kf5-qt5. More details on this
> would be nice )

We could theoretically just tap into a distribution's AppStream database if 
that makes our lives easier, or just reuse their code to extract the data and 
create the database.

___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Our new project metadata system

2016-04-01 Thread Ben Cooksley 
On Fri, Apr 1, 2016 at 4:44 AM, Matthias Klumpp  wrote:
> Hi!
>
> Just adding my 2ct as AppStream maintainer:
>
>  - Centralizing AppStream metadata is IMHO a really bad idea, since it
> makes the life of people wanting to change or update it much harder,
> leading to fewer changes and maybe even less metadata.
>
>  - Using d_eds old script is also a bad idea, since both the spec and
> the script have changed over time - years ago, I used it as basis for
> an initial AppStream metadata push to the KDE repositories, meanwhile
> projects have written and updated their metadata, it has been
> translated, etc. - so using that script again would be a step back.
>  You can find the old metadata *templates* at
> https://github.com/ximion/kde-appstream-metadata-templates , for
> projects which don't have the data yet. I call them templates, because
> they do need to be reviewed and changed, so it's nothing to blindly
> push to a repo. That said, most repositories already have metadata.
>
>  - AppStream metainfo files are very rich in metadata - using a
> markdown document makes it hard to add the same amount of data (e.g.
> that document would need to contain a way to define multiple
> screenshots with descriptions, having listsings with provided items,
> ...). It's not impossible, but saving some time and writing the data
> in XML directly is helpful.
>  To make the metainfo fles in KDE more readable, one could think about
> adding the translation as part of the build process (like GNOME does)
> and not having them added automatically by scripty.
>
>  - AppStream is already really well established - it's used by pretty
> much all major distros, and tools[1] exist to read and write and
> transform metadata.
>
>  - AppStream is extensible - if you miss some functionality, please
> just talk to me and we can discuss adding it to the Freedesktop spec,
> if it's generally useful. If it's something KDE specific, you could
> add arbitrary tags to metainfo files if you prefix them with "x-" (the
> same way non-standard stuff is defined in .desktop files).

Out of curiosity, how are the Appstream files accessed by tools such
as the various app centers?
I presume some kind of repository exists?

If so, it may be worth pulling the information you need Boudhayan from
such a repository ( although the indexing process will undoubtedly
require either source code checkouts or compiled code, in which case
we'll probably have to use what the CI system has and pick a branch
group to represent - probably stable-kf5-qt5. More details on this
would be nice )

>
> Cheers,
> Matthias

Regards,
Ben

>
> [1]:
>  AppStream reading & writing (with limitations, no general data
> transformation, screenshot downloads, etc.) & Qt bindings:
>https://github.com/ximion/appstream
>
>  AppStream distro metadata writing (includes searching icons and
> downloading & resizing screenshots):
>https://github.com/ximion/appstream-generator
>
>  AppStream reading (cache-less) and writing (all modes), used by GNOME
> Software, supports things like firmware & CAB extraction:
>https://github.com/hughsie/appstream-glib
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Our new project metadata system

2016-03-31 Thread Luigi Toscano 
On Thursday 31 of March 2016 14:29:19 Jaroslaw Staniek wrote:
> On 31 March 2016 at 14:18, Luigi Toscano  wrote:
> > On Thursday 31 of March 2016 17:23:37 Boudhayan Gupta wrote:
> > > On 31 March 2016 at 17:13, Luigi Toscano 
> > 
> > wrote:
> > > > Wait, no. The metadata there are outdated, the ones in project
> > > > repositories
> > > > have been updated _and_ translated in the meantime.
> > > 
> > > Where do I find them? I can't find anything in every project's repo
> 
> ​They're sometimes in /, sometimes in src/ and similar subdirs.​
> 
> 
> ​
> https://github.com/search?utf8=%E2%9C%93=org%3AKDE+.appdata.xml=Code;
> ref=searchresults (sorry but I probably can't search this way without github
> :/)

https://lxr.kde.org/search?_filestring=appdata.xml
https://lxr.kde.org/search?v=latest-qt4&_filestring=appdata.xml


-- 
Luigi
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Our new project metadata system

2016-03-31 Thread Jaroslaw Staniek 
On 31 March 2016 at 14:18, Luigi Toscano  wrote:

> On Thursday 31 of March 2016 17:23:37 Boudhayan Gupta wrote:
> > On 31 March 2016 at 17:13, Luigi Toscano 
> wrote:
> > > Wait, no. The metadata there are outdated, the ones in project
> > > repositories
> > > have been updated _and_ translated in the meantime.
> >
> > Where do I find them? I can't find anything in every project's repo
> >
>

​They're sometimes in /, sometimes in src/ and similar subdirs.​


​
https://github.com/search?utf8=%E2%9C%93=org%3AKDE+.appdata.xml=Code=searchresults
(sorry but I probably can't search this way without github :/)

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Our new project metadata system

2016-03-31 Thread Luigi Toscano 
On Thursday 31 of March 2016 17:23:37 Boudhayan Gupta wrote:
> On 31 March 2016 at 17:13, Luigi Toscano  wrote:
> > Wait, no. The metadata there are outdated, the ones in project
> > repositories
> > have been updated _and_ translated in the meantime.
> 
> Where do I find them? I can't find anything in every project's repo
> 

Look for .appdata.xml, where  matches the name of the 
corresponding .desktop file.

Random examples:
https://quickgit.kde.org/?p=kig.git=blob=9daea7d0f9ba90571f0429cd5a4ed0de8d24df74=2f22efe4cb70960cf2362680783477ed44b2492e=org.kde.kig.appdata.xml
https://quickgit.kde.org/?p=yakuake.git=blob=68c7e41ff5a008067228e9ac871f3c53df3289d4=87f7321955c5787717e3dd8fe34ae673bc3eee83=data%2Forg.kde.yakuake.appdata.xml
https://quickgit.kde.org/?p=konsole.git=blob=e53e70ac827eb484a9fbf3b4ba27e677ee5f4489=6c4608b7038174310be18b8e903abd098006b01a=desktop%2Forg.kde.konsole.appdata.xml
https://quickgit.kde.org/?p=kdepim.git=blob=2f5e64206866a8c91b428220f29199bea9b0532b=eef4ef1d8717e7e2fa328dcd21e461dcf2f39ece=kmail%2Fdata%2Forg.kde.kmail.appdata.xml
https://quickgit.kde.org/?p=ark.git=blob=b1d4ad89ff6a8e3aeea0acc910371161c0bda091=f11ecbba02f72d478274cc93b7881a3bc45d19e3=app%2Forg.kde.ark.appdata.xml

-- 
Luigi
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Our new project metadata system

2016-03-31 Thread Jaroslaw Staniek 
+1 for using wider accepted standards, whatever they are, and making life
of distros easier too.

On 31 March 2016 at 12:06, Luigi Toscano  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.
>
> 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=138348776618380=2
> http://marc.info/?l=kde-core-devel=138349411519937=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
> ___
> kde-community mailing list
> kde-community@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
>



-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Our new project metadata system

2016-03-31 Thread Olivier Churlaud 

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, kde-community-requ...@kde.org a écrit :

Message: 8
Date: Thu, 31 Mar 2016 12:06:50 +0200
From: Luigi Toscano<luigi.tosc...@tiscali.it>
To:kde-community@kde.org
Cc:kde-de...@kde.org, KDE Sysadmin Help Desk<sysad...@kde.org>
Subject: Re: [kde-community] Our new project metadata system
Message-ID:<5718636.mftrzcl...@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=138348776618380=2
http://marc.info/?l=kde-core-devel=138349411519937=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
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Our new project metadata system

2016-03-31 Thread Luigi Toscano 
On Thursday 31 of March 2016 12:31:39 Olivier Churlaud wrote:
> Le 31/03/2016 12:07, kde-community-requ...@kde.org a écrit :
> > Message: 8
> > Date: Thu, 31 Mar 2016 12:06:50 +0200
> > From: Luigi Toscano<luigi.tosc...@tiscali.it>
> > To:kde-community@kde.org
> > Cc:kde-de...@kde.org, KDE Sysadmin Help Desk<sysad...@kde.org>
> > Subject: Re: [kde-community] Our new project metadata system
> > Message-ID:<5718636.mftrzcl...@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=138348776618380=2
> > http://marc.info/?l=kde-core-devel=138349411519937=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
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[kde-community] Our new project metadata system

2016-03-31 Thread Olivier Churlaud 

Le 31/03/2016 12:07, kde-community-requ...@kde.org a écrit :

Message: 8
Date: Thu, 31 Mar 2016 12:06:50 +0200
From: Luigi Toscano<luigi.tosc...@tiscali.it>
To:kde-community@kde.org
Cc:kde-de...@kde.org, KDE Sysadmin Help Desk<sysad...@kde.org>
Subject: Re: [kde-community] Our new project metadata system
Message-ID:<5718636.mftrzcl...@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=138348776618380=2
http://marc.info/?l=kde-core-devel=138349411519937=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
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[kde-community] Our new project metadata system

2016-03-31 Thread Boudhayan Gupta 
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).

Of course, only sysadmins have write access to sysadmin repos; not
everyone can upload the files themselves. You can get in touch with
the sysadmins over e-mail, use Phabricator or simply co-ordinate with
your module maintainer who can then send us the files in batches.
Volunteers and anyone willing to lend a hand with the process are most
welcome :-)

Thanks,
Boudhayan Gupta
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community