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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
