[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: Framework metadata
From:       Aurélien_Gâteau <agateau () kde ! org>
Date:       2013-12-20 13:15:33
Message-ID: 1709508.KdXQNlASNA () trinity
[Download RAW message or body]

Le jeudi 19 d=E9cembre 2013 20:50:43 Nicol=E1s Alvarez a =E9crit :
> 2013/12/19 Aur=E9lien G=E2teau <agateau@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, s=
o =

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 ou=
t.

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 Ale=
x =

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 i=
s =

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 dependenc=
y =

on kinit, or kdnssd optional dependency on kconfig).

Are we all OK with this short-term plan?

Aur=E9lien

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[prev in list] [next in list] [prev in thread] [next in thread]