metadata in xdg-specs
Aaron J. Seigo
aseigo at kde.org
Tue Jan 11 15:35:18 PST 2011
On Tuesday, January 11, 2011, Cornelius Schumacher wrote:
> On Tuesday 11 January 2011 Aaron J. Seigo wrote:
> > anything else that should be included? any thoughts on format?
> For reference here are some proposals from a while ago:
> Especially a proposal for a process including how to deal with metadata:
> Not sure how much of that still is relevant, but maybe it helps in some
i just (re-)read the spec process file and imho it's still 100% relevant.
what we need is someone(s) from the GNOME and the KDE commuities to offer
feedback on it and if/once we get to agreement on it, let's simply start
putting it into practice.
hopefully Vincent or another GNOME developer can aid in bringing the GNOME
perspective to it?
the xml format could probably use with some tweaks and a proper description of
the syntax could be created as well once agreed upon. some initial thoughts:
* authorinitials probably not needed?
* in my initial test implemention, using UIDs from a vcard proved nice for the
machine (e.g. to generate reports) but not so great for humans. :) so perhaps
instead of vcard UIDs we could just put names and enforce a convention that
the name as written in the xml file must match an entry in an addressbook we
keep centrally somewhere. i think we can rely on people not to change their
names very often ;) .. email addresses, etc. are more transient, though, and i
still think we should avoid sprinkling them around in documents
* the contributors section duplicates what is in the docbook formatted spec
itself, so perhaps we can just drop that entirely for now. it'd be nice to
have, but we can probably rip through the docbook sources to get the same
information for report generation. as long as the authorship info stays in the
docbook, there's really no point to duplicating the info. i would like to see
clear maintainership notes in the docbook, though.
* whether revhistory is needed here or not probably depends on how we handle
the git repository itself. e.g. if only "release" and "patch level" versions
of a spec are committed to master, then we can use git log for that instead.
otherwise, i'm still in favor of the approach (as is probably completely
evident by now ;)
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the xdg