Framework metadata

[Aurélien Gâteau]

Le jeudi 19 décembre 2013 20:50:43 Nicolás Alvarez a écrit :
> 2013/12/19 Aurélien Gâteau <agateau at kde.org>:
> > On Thu, 19 Dec 2013 12:13:08 +0200, Giorgos Tsiapaliokas wrote:
> >> I definitely like the idea but I don't like xml/rdf. Why don't we just
> >> use json?
> > 
> > Because DOAP is an existing format, so it avoids reinventing the wheel.
> 
> Everyone please keep in mind that DOAP is not an XML format, it's an
> RDF format which is often serialized with RDF/XML, and there are many
> ways to specify the same RDF graph in RDF/XML.
> 
> Assuming appropriate namespace declarations, all these are equivalent:
[snip]
> And this is just a simple example with literal strings, I didn't even
> add references to other resources (as it would be needed for
> doap:maintainer). To parse it you *really* need an RDF library, not
> just an XML parser. Do we really want this complexity?

That is true. However we can avoid that trap since we would be writing the 
DOAP files ourself, so it would be easy to standardize on the simplest form: 
*our* code reading *our* files does not need to support the other forms.

Nevertheless, given the strong opposition I feel against anything XML, I am 
afraid that thread can go on for a long time, especially with the upcoming 
Christmas break, but we need action now. I will be mostly offline until 
January 6th, but I want to be able to get things done during this period, so 
here is what I propose: a simple short-term solution, aimed at getting 5.0-tp1 
out. We can revisit it after Santa brought us fancy gifts and 5.0-tp1 is out.

Mandatory files for a framework:

# README

Formatted in Markdown. Contains a high level overview of the framework and 
links to:
- mailing list
- IRC channel
- git repo
- bugtracker
- reviewboard

# INSTALL

Formatted in Markdown. Contains generic install instructions, following Alex 
Merry suggestion, except if the framework requires specific settings.

# COPYING.*

Classic license files

# $framework.yaml

Anything necessary for kf5dot to generate the dependency diagrams. Yes it is 
YAML, not JSON, for the reasons I outlined before.

I expect this file to be as simple as:

	tier: 3
	type: integration

kf5dot requires at least the "tier" information but I may add other things,  
like "hidden" dependencies not caught by cmake graphviz (ex: kded dependency 
on kinit, or kdnssd optional dependency on kconfig).

Are we all OK with this short-term plan?

Aurélien