On Wednesday 08 July 2009 19:52:32 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). 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 agree. In KDE the way we handle additions to kdelibs (in general) is that if the code in question is currently in use by 2 or more applications we try to push it into kdelibs. Similarly here, we could say that something "becomes" an fd.o spec after being in use by 3 or more projects (or 2 or more if KDE or GNOME is using it) per the metadata in the repository. Other alternatives are simply voting (but who gets to vote?), throwing it up and seeing if it gets NAK'ed by a project (but that's a sure way to never see another xdg spec...), and I'm sure we could come up with a dozen other ways. I think I agree with Aaron in that it would be nice to remove the *requirement* for human interaction/setup/approval as much as possible from the process, which would also point back to using the repository to track "used-ness" of a spec, with a script that could promote it to a standard automatically. Only other feasible automatic method I can think of is submitting a spec as a proposal, and then projects can either accept/ignore/reject a proposal in the repository. After a set amount of time (3 weeks?) a proposal that has at least twice as many accepts as rejects automatically becomes an fd.o spec. > 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? I think the worry is about competing specs. But I can certainly see the case where several DEs have a spec for something that the other DEs simply don't care about yet, and that's no reason to keep the spec unapproved. So I agree that the criteria GNOME+KDE is too simplistic. Regards, - Michael Pyne
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
