I wrote a long email to desktop-devel-list and gnome-infrastructure about doap files. I’d like to require these files and drop the /trunk/MAINTAINERS file requirement.
Excerpt from the mail:
Currently project information is spread thoughout various systems. The maintainers are available in MAINTAINERS files, developers in AUTHORS, the description is possibly in either Bugzilla or some README file, etc. I’d like to make use of DOAP files for this.
See for example the usage of DOAP on projects.apache.org:
- http://svn.apache.org/repos/asf/ant/core/trunk/doap_Ant.rdf
- http://projects.apache.org/projects/ant.html
Examples of what is in a DOAP file:
- maintainers
- long description
- releases
- homepage / download link
- bugtracker link ()
- repository info (SVN + viewvc)
And others:
- short description
- mailing lists
- various kinds of contributors
- programming language
- category
- etc
Please read the email as I don’t want to repeat the whole thing. Comments welcome (preferrably on d-d-l).
Hell! No! No chance that I’ll maintain such a bloat!
There are reasons, some ideas are not adopted. In the case of DOAP: Far too much work for no use.
I’ve been maintaining a DOAP file in Clutter, and it’s quite easy to dump somewhere, read via a cron job and generate a project page from a template.
also, if the install-module script just added the releases itself it would be even easier.
Ow! My eyes my eyes!! That is one hell of an ugly file.
Wouldn’t it be better to keep this information in human-readable files? I don’t mind a file being machine readable too, but not at the expense of humans being able to glance at it and quickly see the information they want.
I give this idea a -1. I would reconsider if you could find a less hostile file format.
sb: It needs to readable enough to be editable. For normal users/developers there will eventually be some website where this is shown in a nice layout, etc. My goal is using this data in the infrastructure, etc.