On Thursday 31 of March 2016 12:31:39 Olivier Churlaud wrote: > Le 31/03/2016 12:07, [email protected] a écrit : > > Message: 8 > > Date: Thu, 31 Mar 2016 12:06:50 +0200 > > From: Luigi Toscano<[email protected]> > > To:[email protected] > > Cc:[email protected], KDE Sysadmin Help Desk<[email protected]> > > Subject: Re: [kde-community] Our new project metadata system > > Message-ID:<[email protected]> > > Content-Type: text/plain; charset="us-ascii" > > > > On Thursday 31 of March 2016 13:55:03 Boudhayan Gupta wrote: > >> >Hi all, > >> > > >> >Over the last few weekends we've been doing some spring-cleaning to > >> >our infrastructure. You may have noticed that we've killed off > >> >projects.kde.org, and we have new scripts that generate our > >> >kde_projects.xml without having to depend on ChiliProject now. We're > >> >also planning to deprecate kde_projects.xml itself, and to that effect > >> >we've started setting up a JSON/REST API at > >> >https://apps.kde.org/api/v1/. > >> > > >> >The same infrastructure that is used to generate data for our API and > >> >the XML file can be used to generate a HTML website with landing pages > >> >for our applications, and this is something we intend to do in the > >> >coming months as a replacement for the outdated kde.org/applications > >> >site. To achieve that, however, we're going to need some help from > >> >you. > >> > > >> >Our project metadata is currently held in the sysadmin/repo-metadata > >> >repository. We currently hold data about the project name, repository > >> >and a one-line description of each project. We would like maintainers > >> >and anyone who can help to provide us with three things for every > >> >project - a*description.md* file with a bigger description of each > >> >project that appears on the website, and for applications with a GUI, > >> >a*screenshot.png* file with a screenshot of the app and two icons (a > >> >256 * 256 px icon.png and a 512 * 512px icon_2x.png). > > > > I don't think we need to do this; we have AppStream metadata. > > > > Long time ago it was in fact discussed how to not duplicate the > > information > > between the json on the website and the AppStream metadata. There was some > > idea on how to generate one from the other. Check this old thread on > > kde-core- devel, from November 2013 ("Adopting AppData in KDE? > > http://marc.info/?l=kde-core-devel&m=138348776618380&w=2 > > http://marc.info/?l=kde-core-devel&m=138349411519937&w=2 > > > > And also, more recent: > > https://mail.kde.org/pipermail/kde-community/2015q4/002132.html > > > > Now, whether we like them or not, those metadata are already available and > > going to stay. I don't think we want to duplicate again the same set of > > data for the website. > > > > I would say then to use them for the website, adding the missing files in > > the process (most of applications are already covered). > > > > Ciao > > -- Luigi > > Hi, > > During the CERN Sprint we worked with Alex Merry on something similar, > without knowing you were doing the same. Our idea is to have all > metadata to generate a comprehensive api.kde.org. > > You can see the notes here: https://notes.kde.org/p/apidox (please do > not edit, even if I have a copy). I'm currently working on the the > script that could generate the doxygen documentation from this, before > releasing the proposition. > > These "config.apidox" files should just add infos that are not in > "metadata.yaml". Maybe we should work together to have one global > system, that can be used by everyone? > > If it's not related to the topic, then sorry for the noise :S
I think it's different: you are talking about generating api.kde.org (and maybe, if I remember the past discussion, the entire techbase). This is about the project pages for kde.org and, more generally, the metadata for each application/library/git repository. Ciao -- Luigi _______________________________________________ kde-community mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-community
