Summary of the fdo disussion at GCDS

[Aaron J. Seigo]

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

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 
participation

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
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090708/511a1ea1/attachment.pgp