Summary of the fdo disussion at GCDS
mpyne at purinchu.net
Wed Jul 8 20:15:37 PDT 2009
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
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.
- Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090708/160f68ed/attachment.pgp
More information about the xdg