Re: [kde-community] Our new project metadata system
On 2 April 2016 at 15:39, Thomas Pfeifferwrote: > 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
On 31 March 2016 at 12:43, Luigi Toscanowrote: > 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
On Fri, Apr 1, 2016 at 3:13 PM, Boudhayan Guptawrote: > 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
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
On Fri, Apr 1, 2016 at 4:44 AM, Matthias Klumppwrote: > 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
On Thursday 31 of March 2016 14:29:19 Jaroslaw Staniek wrote: > On 31 March 2016 at 14:18, Luigi Toscanowrote: > > 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
On 31 March 2016 at 14:18, Luigi Toscanowrote: > 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
On Thursday 31 of March 2016 17:23:37 Boudhayan Gupta wrote: > On 31 March 2016 at 17:13, Luigi Toscanowrote: > > 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
+1 for using wider accepted standards, whatever they are, and making life of distros easier too. On 31 March 2016 at 12:06, Luigi Toscanowrote: > 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
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
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
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
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