Summary of the fdo disussion at GCDS

[Aaron J. Seigo]

On Wednesday 08 July 2009, 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).

you are correct that it doesn't answer this question. that was purposeful, 
actually, because while i felt comfortable devising a way to structure and 
document what we're working on together, defining what constitutes "enough 
support" to then qualify for official fd.o status is something we need to do 
together as a group. i really didn't feel like i could even begin that 
solution on my own, it requires discussions and consensus.

first, we need to be able to measure what we do and know how we do it. that 
was the extent of my proposal. and you are also correct that the next thing we 
need to do after that is define "what constitutes enough support"

> 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.

agreed ...

> 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?

there are a few aspects to this one:

* KDE + GNOME have the lion's share (by far) of the F/OSS desktop market, so 
if one goes by market share representation any approval would require those 
two groups

* however, many eyes make proposals good ... maybe it shouldn't be strictly 
market share

* "KDE + GNOME" tends to assume that it will always be that way, that there 
won't be others with as much market share

* it is likely that at some future point others will get involved with fd.o 
once it is running better that represent fairly unique interests; maemo and 
moblin might be examples of that

* if we do take into account other projects, who are already involved here 
such as XFCE/LXDE/Enlightenment, then we probably need to find a way to weight 
things so it's still representative (similar to how it's common to have a 
House of Representatives where each state/province/canton gets a # of seats 
relative to population size). how it should be weighted is probably a pretty 
lengthy discussion, and still doesn't take into consideration future changes. 
in any case, it could be as simple as saying that "XFCE, LXDE, Enlightenment, 
etc." represent one bloc in equality to KDE and GNOME, and a spec needs 2/3 
blocs with no bloc registering an objection. regardless of the actual 
weighting, the measuring is easy as long as we document acceptance in a 
machine-readable format. so the weighing would be light weight as a process, 
but coming up with how to weigh will not be.

regardless, we'll need to adjust it over time if/as the market conditions 
change. this can not be something set in stone, but must be a living document 
that reflects the nature and character of our group here.

so .... taking all the above into consideration, i would suggest:

* we provide a process in which ALL projects can register their acceptance, 
implementation, rejection, etc of specs

* we recognize that out of pragmatism we settle on KDE+GNOME, for the 
immediate time period (which is better than the current "nobody, every body"  
non-method)

* we work on ironing out and practicing the processes we do put in place

* we revisit the representational acceptance issue in a 6-12 months time once 
we have the basics working and in place.

yes, it's not perfect, but it's something we can achieve and which we can use 
as a stepping stone towards perfection. we just need to recognize it as a 
stepping stone, and not the final destination. personally, i'm ready for a few 
years of effort here before we're in a place i'm personally happy with. :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090709/e9cee139/attachment-0001.pgp