Re: [kde-community] KDE Mission - let's do this!

[Alexander Neundorf]

On Wednesday, March 30, 2016 22:43:03 Thomas Pfeiffer wrote:
> Hi everyone,
> now that we've finally agreed on a vision for KDE [1] and have that out of
> the way, we can fully focus on how we want work towards that vision.
> Alex has already set up a Wiki page for brainstorming notes [2], so it would
> be great if everyone who has opinions or ideas about how we can nudge the
> world towards the one we envision could add them to it.
> It's really just brainstorming, no ideas are "bad" or anything, everyone and
> everything is welcome!
> 
> I'd suggest that we let the brainstorming phase last until Friday and then
> start discussing the ideas collected on that Wiki page.

two days is quite short (I just saw it right now).
Let's have a week at least, i.e. April 10th ?

Alex

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

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

[Thomas Pfeiffer]

On Donnerstag, 31. März 2016 13:43:55 CEST 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.
> > We're not duplicating anything. We're trying to trim down the number
> > of places where you can find metadata to *one* location, and then
> > generating everything else from there.
> 
> So you consume the existing AppStream metadata from each project repository.
> As I said, they are well handled and translated. No need to import them in
> the centralized store.

I agree with Luigi: Allowing maintainers to update their metadata in their own 
repositories and then generating the central database from this is likely the 
best way.
For many maintainers, filling in metadata feels probably more like a burden 
than fun, so we have to at least make this as easy for them as possible.

We also need people to update their AppStream data with release notes for 
every release, so we can use them in Discover as well as on the websites. This 
is definitely not something we want every project to file a sysadmin ticket for 
every release for.
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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

[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&q=org%3AKDE+.appdata.xml&type=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

[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&q=org%3AKDE+.appdata.xml&type=Code&ref=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

[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&a=blob&h=9daea7d0f9ba90571f0429cd5a4ed0de8d24df74&hb=2f22efe4cb70960cf2362680783477ed44b2492e&f=org.kde.kig.appdata.xml
https://quickgit.kde.org/?p=yakuake.git&a=blob&h=68c7e41ff5a008067228e9ac871f3c53df3289d4&hb=87f7321955c5787717e3dd8fe34ae673bc3eee83&f=data%2Forg.kde.yakuake.appdata.xml
https://quickgit.kde.org/?p=konsole.git&a=blob&h=e53e70ac827eb484a9fbf3b4ba27e677ee5f4489&hb=6c4608b7038174310be18b8e903abd098006b01a&f=desktop%2Forg.kde.konsole.appdata.xml
https://quickgit.kde.org/?p=kdepim.git&a=blob&h=2f5e64206866a8c91b428220f29199bea9b0532b&hb=eef4ef1d8717e7e2fa328dcd21e461dcf2f39ece&f=kmail%2Fdata%2Forg.kde.kmail.appdata.xml
https://quickgit.kde.org/?p=ark.git&a=blob&h=b1d4ad89ff6a8e3aeea0acc910371161c0bda091&hb=f11ecbba02f72d478274cc93b7881a3bc45d19e3&f=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

[Boudhayan Gupta]

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

-- 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

[Luigi Toscano]

On Thursday 31 of March 2016 17:10:13 Boudhayan Gupta wrote:
> Hi all,
> 
> On 31 March 2016 at 16:14, Jaroslaw Staniek  wrote:
> > +1 for using wider accepted standards, whatever they are, and making life
> > of distros easier too.
> 
> Making life for distros easier is one of the primary goals for this,
> 
> and apps.kde.org will fulfil that need, see below for more:
> > 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.
> 
> We do need to do this, because AppStream metadata will also eventually
> be generated from this repo. I'll do an initial import of data from
> d_ed's AppData XML files, for now.

Wait, no. The metadata there are outdated, the ones in project repositories 
have been updated _and_ translated in the meantime.
> 
> >> 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
> 
> The idea here is to hold all the metadata in one place in a format
> which is easy for humans to manipulate, and from which we can generate
> all other metafiles.

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.

> 
> We're not duplicating anything. We're trying to trim down the number
> of places where you can find metadata to *one* location, and then
> generating everything else from there.

So you consume the existing AppStream metadata from each project repository. 
As I said, they are well handled and translated. No need to import them in the 
centralized store.

-- 
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

[Boudhayan Gupta]

Hi all,

On 31 March 2016 at 16:14, Jaroslaw Staniek  wrote:
>
> +1 for using wider accepted standards, whatever they are, and making life of
> distros easier too.

Making life for distros easier is one of the primary goals for this,
and apps.kde.org will fulfil that need, see below for more:

> 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.

We do need to do this, because AppStream metadata will also eventually
be generated from this repo. I'll do an initial import of data from
d_ed's AppData XML files, for now.

>> 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

The idea here is to hold all the metadata in one place in a format
which is easy for humans to manipulate, and from which we can generate
all other metafiles.

For now, we use this data (held in sysadmin/repo-metadata) to generate
only kde_projects.xml and our JSON replacement for the same.

Unless I'e made a mistake, David Edmundson's script (in
http://marc.info/?l=kde-core-devel&m=138349411519937&w=2) seems to
generate AppData from the kde website. Said website is out of date and
does not contain info for newer apps (in fact, I couldn't find a page
for Spectacle). I see we've got the screenshots updated, so that's
awesome.

In any case, we'll be importing whatever data we can find from
kde.org/applications into repo-metadata. repo-metadata will become the
*only* place where metadata is kept; all other metafiles (XML, JSON,
AppData, the website) will be generated from there.

This ensures that metadata is never out of sync. The AppData, website,
JSON, and XML will always carry the same data.

>> 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.

We're not duplicating anything. We're trying to trim down the number
of places where you can find metadata to *one* location, and then
generating everything else from there.

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

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

[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&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
> ___
> 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

[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
To:kde-community@kde.org
Cc:kde-de...@kde.org, KDE Sysadmin Help Desk
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&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
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [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-requ...@kde.org a écrit :
> > Message: 8
> > Date: Thu, 31 Mar 2016 12:06:50 +0200
> > From: Luigi Toscano
> > To:kde-community@kde.org
> > Cc:kde-de...@kde.org, KDE Sysadmin Help Desk
> > 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&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
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[kde-community] Our new project metadata system

[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
To:kde-community@kde.org
Cc:kde-de...@kde.org, KDE Sysadmin Help Desk
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&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
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

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

[Luigi Toscano]

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
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] KDE's 20th birthday

[Clemens Toennies]

Am 31.03.2016 um 09:22 schrieb Lydia Pintscher:
> On Sat, Aug 1, 2015 at 3:49 PM Lydia Pintscher  > wrote:
>
> Hey folks :)
>
> Next year in October we will celebrate KDE's 20th birthday. This is
> still quite a bit in the future but we should start brainstorming
> ideas for what to do. I've started a wiki page:
> https://community.kde.org/20th_birthday Please add your ideas.
>
>
> Hey folks :)
>
> I wanted to bring this up again as we need to get going in order to
> make a splash at QtCon about our 20th anniversary this year. Please go
> ahead and add your ideas. Even better: Anyone up for stepping up to
> lead this?

I really like what is already there, especially the points from Alex N.
They make it very clear how we aim to go for the KDE vision, so +1 from me.

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

[kde-community] Our new project metadata system

[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

Re: [kde-community] KDE's 20th birthday

[Lydia Pintscher]

On Sat, Aug 1, 2015 at 3:49 PM Lydia Pintscher  wrote:

> Hey folks :)
>
> Next year in October we will celebrate KDE's 20th birthday. This is
> still quite a bit in the future but we should start brainstorming
> ideas for what to do. I've started a wiki page:
> https://community.kde.org/20th_birthday Please add your ideas.
>

Hey folks :)

I wanted to bring this up again as we need to get going in order to make a
splash at QtCon about our 20th anniversary this year. Please go ahead and
add your ideas. Even better: Anyone up for stepping up to lead this?


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