Summary of the fdo disussion at GCDS

[Aaron J. Seigo]

On Wednesday 08 July 2009, Cornelius Schumacher wrote:
> Some notes from me as I attended the discussion at GCDS.
>
> The basic idea, which was brought up by Robert McQueen, is to create a
> light-weight process to accept specifications as standard cross-desktop
> specs approved by freedesktop.org. The process would be that a spec is
> accepted as freedesktop.org spec, if the release teams of both GNOME and
> KDE accept the spec.

this sounds great; but it's very high level, so let's talk implementation.

> On Wednesday 08 July 2009 23:01:54 Aaron J. Seigo wrote:
> > 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?
>
> In the end it doesn't matter too much where they are. freedesktop.org would
> be the place where there is a list clearly stating which specifications are
> accepted as a freedesktop spec.

and then to get them i have to travel all over the internet? at the very least 
it's inconvenient, more likely it's impractical (how do we keep backups we can 
rely on, btw?) and will in cases be a blocker to community involved (putting a 
spec up in a read only area of the web or tucked away in a source code 
repository). at worst, it will cause confusion.

separating where something is documented and the thing being documented itself 
gives you no benefit, but it does open the door for discrepancies.

i can easily put a spec up on my website and in it claim or even just imply it 
is an fd.o spec. someone visiting will likely believe that is so unless there 
is a canonical location for specs to be kept. few will go check the "official 
list" somewhere else if the spec itself says it's all good.

this is not a scenario that requires malice, only simple mistakes. c.f. 
galago.

> > 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)
>
> The idea was that fd.o would only host accepted implementations, in case
> hosting is not solved in another way already.

sounds good; and the acceptance would be measured in the same way as a non-
implementation spec? e.g. a piece of software would submit a descriptive 
design document and the projects would be able to accept/reject/abstain in the 
same manner as, say, the icon or visual notifications specs?

> > > 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.
>
> As said before the release teams of GNOME and KDE would be the defined
> points of contact, which take the decision about acceptance.

points of contact and decision making are not necessarily the same thing. our 
release team has enough to do as it is, they don't need to be following every 
single spec. in fact, as you note, what they will likely do is simply ask Tom 
who knows a lot about Foo what he thinks and then just pass on his result. so 
why not just let Tom do this directly? 

also, this allows projects that don't have as big an infrastructure as GNOME 
or KDE to get involved. even if their accept/reject/abstain is only 
informational (e.g. doesn't go towards official acceptance by fd.o) it allows 
for things like what we have with the EWMH spec: a huuuge list of window 
managers that support it and at which level. this is useful information to 
third parties.

if we go the repository route this is zero overhead to coordinate: each 
project would simply send whomever they wish to do the work. maybe it's the 
release team, maybe it's Tom who knows a lot about Foo, maybe it's the guy who 
writes some window manager.

> This of course
> would in most cases mean to delegate the decision to the people involved in
> the specs under question, but as the release teams already act in a similar
> role for the individual communities, it seemed logical to extend that to
> the common activities in freedesktop.org.

i don't think that is true of every entity that may one day be involved, and i 
have my doubts about our own release team given their current work load as it 
is.

> Bottlenecks are a concern, but in
> this case there seems to be a good chance that the existing structures
> prevent that to happen.

why not create a system where there are no bottlenecks in the first place? 
then we don't have to worry. i really don't understand this "bodge it 
together" mentality. defining a system that scales is not hard.

> > 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.
>
> Yes, a spec rejected by one of the communities would be marked and
> documented as such. Same goes for other aspects of the status of the spec,
> where we need to document, e.g. if it's proposed, or implemented, or
> deprecated, etc.

good; what format will we be using for this documentation? it should be 
machine readable so we can easily create reports based on the data ("which can 
i rely on gnome 2.20 implementing?" "which specs are implemented by both gnome 
and kde as for 2009?" "which specs have objections?" etc..)

also note that proposed and deprecated are per-spec, but implementations may 
be per-project. while we have one dbus implementation (at least currently) we 
have N different implementations of the icon, EWMH, notifications, d'n'd, etc, 
etc specs.

> > > 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.
>
> The details of how to organize this best should be sorted out by the two
> release teams. Maybe a new dedicated mailing list would be a solution,
> tracking requests in Bugzilla, or some other implementation. Whatever is
> most practical.

a new mailing list hardly solves the problem that email is not suited to the 
task.

bugzilla is a possibility, though probably quite cumbersome (it's not set up 
for multiple projects to weigh in their status in an easy to follow way).

both methods also cause separation between spec and documentation. if i update 
the spec, i have to travel somewhere completely different to update the 
documentation. we all know how non-easy synchronization of data is in 
software, why are trying to do this with our more error prone human software?

i hate to keep beating this drum, but a repository in which to store this 
resolves the issues handily.

when i proposed the repository approach, that wasn't something i plucked out 
of thin air. i considered the role of email, bug reporting systems, wikis, ... 
i ruled them out for various inherent weaknesses. remember that the process 
used will create social behaviors that cause the results; the repository 
approach puts the least amount of weight on social behavior and lets the 
software do as much as possible.

> > 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.
>
> There is nothing wrong with that. It might be the right implementation of
> the idea. That's something we still have to sort out.

the email i just read said we'd use a wiki page. talking with others who were 
there it seems that the proposal was to run the whole thing via wiki.

then there are the bits about using mailing lists and who ratifies. 

these are implementation details, ones that run rather counter to what i've 
brought to the table here and ones in which i can no faith will work for the 
reasons i'm sharing.

so please, don't brush it aside with "that's something we still have to sort 
out" because we are sorting it out right here: wikis, mailing lists, release 
teams. if we pretend we aren't creating concrete process when we talk about 
wikis, mailing lists and release teams we're fooling ourselves and will create 
a botched process.

> > it makes it easier to miss a spec, or for multiple versions of the spec
> > to start cropping up.
>
> We would have a central place on freedesktop.org, which would clearly show
> which specifications are accepted, and where they are.

absolutely agreed. in the repository model, that would be repository (which 
conveniently also comes with the specs themselves) as canonical source and the 
web pages would be populated with an automated script that rips through the 
machine readable documentation.

zero people, always up to date, verifiable.

> The fd.o admins
> would do the administrative work of hosting this list, and the release
> teams would decide about what is listed there and in which state.

done right, the fd.o admins do no have to involved in this at all, which would 
be one more bottleneck removed.

seriously, replacing one bottleneck (the fd.o admins) with a chain of two of 
them (two release teams feeding admins) is going the wrong direction. we 
should want fewer bottlenecks, not longer chains of communication 
distillation. each bottleneck and each hand off between them increases the 
failure rate.

> > 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?
>
> We didn't explicitly discuss this model. I think it could be seen as an
> implementation of the process we discussed. This is something which has to
> be sorted out over the next time. But I don't think it's in conflict with
> the basic idea of the process which was proposed.

it's not in conflict with the basic idea, but with the implementation of the 
idea as presented. the two are different implementations with likely very 
different outcomes.

-- 
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/79900f03/attachment-0001.pgp