Summary of the fdo disussion at GCDS
Aaron J. Seigo
aseigo at kde.org
Wed Jul 8 14:01:54 PDT 2009
On Wednesday 08 July 2009, Olivier Goffart wrote:
> We agreed that freedesktop would have a wiki page listing the
> specification/implementations and saying whether they are blessed by each
> desktop, and the implementation status.
and the specifications themselves go where?
and i assume that software implementations must be accepted first before being
eligible for fd.o hosting? (though i personally think fd.o hosting of software
isn't really necessary these days in most cases)
> In order to get blessed, it has to be accepted by the 'release manager' of
> the desktop.
so we're back to gatekeepers instead of letting the people in each project who
are directly involved with those projects figure it out? i don't see the need
to say how a project represents itself. if a project wants to have one fd.o
rep, so be it. if a project wishes to have one group of people oversee the PIM
related stuff and another group oversee the desktop shell stuff, etc.. so be
having established contact points is good, but defining the agents who will
officially accept proposals too tightly will lead to overworked bottlenecks in
the process. we will, in short, likely end up repeating our current situation.
there's also the issue of rejection. a project should be able to officially
reject a specification. this is useful information for 3rd parties and is
quite different than silence on the matter. if two projects are using it (say,
KDE and XFCE, for whatever reason) and GNOME says "we reject that
specification" that will likely matter to people considering implementing that
spec. if GNOME was silent in that case, it might just mean they haven't looked
at it yet. being able to register "we've looked, we don't want this" should be
part of the plan.
> When someone want to start a project or specification, the suggested
> process would be:
so the proposal is that we do a bunch of asynchronous emailing about and try
and document the emails after the fact.
if i miss an email, then what?
if the person in $PROJECT who should be looking into it misses it, then what?
if the person in $PROJECT who should be looking into it goes away and hands it
off to someone else, then what?
if someone else in $PROJECT has something to add, then what?
this is a process that will fail. the communication requires everyone is
paying attention at the right times and that the communication is then
documented after the fact. there are too many cracks in there to fall through.
expecting people to monitor mailing lists with infallibility is not realistic.
or have we really learned nothing from the last few years where people have
put things on this list and they were missed / ignored / etc?
so again, i ask: what is wrong with putting all of this in a shared repository
where one can do a simple "git pull" and get all the changes regardless of:
* who you are
* when you do it
and when you put your blessing upon something, if it was in a repository then
the documentation of that blessing would be simultaneous with the
communication. in fact, it would be the same act.
> How the spec/project is developed is up to each project. git has been
> suggested but is not mandatory.
so that we have things scattered everywhere? for software projects, sure. but
not having a central place for the specs only makes it harder on everyone.
it makes it harder for 3rd parties find them
it makes it harder for people who are otherwise involved with fd.o to work in
a given spec as they now have to go out and find where it is, with no
guarantee that it's even published in a way that allows community
it makes it easier to miss a spec, or for multiple versions of the spec to
start cropping up.
there is exactly zero benefit to letting specs scatter to the wind, and lots
of benefit to having the specs housed together.
btw, did any of you read what i wrote about the motivations and processes of
the repository based model? was it shared as an option in the discussions at
GCDS? if so, what were the objections or reasons for not wanting to address
all the issues raised in what i wrote?
p.s. as an aside, the word "blessing" is a loaded term that implies certain
emotional and even political aspects that shouldn't exist in the process.
"accept", "reject", "abstain", "implement" are much more value-neutral words.
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/20090708/511a1ea1/attachment.pgp
More information about the xdg