Summary of the fdo disussion at GCDS

[Michael Pyne]

On Wednesday 08 July 2009 19:52:32 Jannis Pohlmann wrote:
> The main problem I still see with this approach is that it doesn't
> really answer the question when to grant a specification the fd.o
> status (as in: under which conditions). This is only really relevant
> for specs that require namespaces (e.g. the icon naming spec doesn't,
> but specs based on D-Bus interfaces do, specs involving XML formats do,
> and the same goes for libraries with fdo or xdg in their name).
> Answering this question is really important.

I agree.  In KDE the way we handle additions to kdelibs (in general) is that 
if the code in question is currently in use by 2 or more applications we try 
to push it into kdelibs.

Similarly here, we could say that something "becomes" an fd.o spec after being 
in use by 3 or more projects (or 2 or more if KDE or GNOME is using it) per 
the metadata in the repository.

Other alternatives are simply voting (but who gets to vote?), throwing it up 
and seeing if it gets NAK'ed by a project (but that's a sure way to never see 
another xdg spec...), and I'm sure we could come up with a dozen other ways.

I think I agree with Aaron in that it would be nice to remove the 
*requirement* for human interaction/setup/approval as much as possible from 
the process, which would also point back to using the repository to track 
"used-ness" of a spec, with a script that could promote it to a standard 
automatically.

Only other feasible automatic method I can think of is submitting a spec as a 
proposal, and then projects can either accept/ignore/reject a proposal in the 
repository.  After a set amount of time (3 weeks?) a proposal that has at 
least twice as many accepts as rejects automatically becomes an fd.o spec.

> I personally disagree with accepting a spec only if is implemented by
> both, GNOME and KDE. If a spec is implemented by KDE, Xfce and
> Enlightenment and maybe several other applications/environments, is that
> under no circumstances relevant and worth considering as an fd.o spec?

I think the worry is about competing specs.  But I can certainly see the case 
where several DEs have a spec for something that the other DEs simply don't 
care about yet, and that's no reason to keep the spec unapproved.  So I agree 
that the criteria GNOME+KDE is too simplistic.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090708/160f68ed/attachment.pgp