Summary of the fdo disussion at GCDS

[Jannis Pohlmann]

On Thu, 9 Jul 2009 09:58:43 +0200
Cornelius Schumacher <schumacher at kde.org> wrote:

> On Thursday 09 July 2009 01: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.
> 
> This is indeed the essential question we have to answer. The answer
> we came up with at the meeting was to come up with the simple
> condition that, if GNOME and KDE, represented by their release teams,
> accept a spec, then it's granted the fd.o status.
> 
> Of course you could also come up with more fine-grained conditions
> including more communities, but that would require a much more
> complex mechanism. Especially the question who is eligible to vote
> about a fd.o spec can become very difficult. At the moment GNOME and
> KDE pretty clearly cover the majority of desktop users, so it seems
> like the most pragmatic and simple solution. Of course this could
> change in the future, if another desktop becomes very popular, but
> today I think it's a good enough approximation that GNOME and KDE
> together cover the majority of the desktop and that against one of
> the two communities you can't push a spec to fd.o acceptance.
> 
> That said, it doesn't mean at all that only specs relevant to GNOME
> or KDE should be fd.o specs. Other communities obviously also have to
> be involved and have the same rights to propose and implement specs.
> It's really only about a well-defined, simple, and transparent
> mechanism to grant fd.o acceptance.

Well, you have an ambiguity there. Simply saying "specs require to be
accepted by both, GNOME and KDE" on the one hand and "sometimes, specs
can also be accepted even if they are not accepted by GNOME and KDE" is
not going to work. 

We recently redesigned our release model and while doing so, I figured
out that if your goal is to define a process that will be accepted by
people, you need to get rid of ambiguity. If the model allows
situations where people are not sure how to decide and what to do, then
it is flawed. Of course the first few process iterations will always
make flaws visible, that's normal.

I think the same applies here. The above is way to ambiguous as far as
I'm concerned, but I'd be happy to decide on something defined a little
better and give it a try for one or two iterations. If we need to
tweak the process later based on our experiences, that's fine.

That being said, I kinda like Jakob's suggestion to give 2 points
to GNOME and KDE each, and 1 point to Xfce, LXDE, Enlightenment and
other desktops/projects and grant specs the fd.o status once they reach
4 points. I don't know if it's perfect or even good enough but at least
it's very simple and well-defined ;)

Ok, I'm going to read your fd.o specification process draft now.

  - Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090710/5992ffd6/attachment.pgp