Summary of the fdo disussion at GCDS
Aaron J. Seigo
aseigo at kde.org
Thu Jul 9 02:38:31 PDT 2009
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.
> 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
* however, many eyes make proposals good ... maybe it shouldn't be strictly
* "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"
* 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
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090709/e9cee139/attachment-0001.pgp
More information about the xdg