On Tuesday, January 11, 2011, Marco Martin wrote: > On Tuesday 11 January 2011, Aaron J. Seigo wrote:
> > so while i agree with your suggested workflow in general, i suggest we > > define "agreed upon" as meaning "at least the first actual release of the > > spec with at least one production implementation". thoughts? > > that could be nice, either one fully working or two with the second at > least partial? > I think is important to agree when one can be considered "real" also for > some quite pratic implications: for instance if the spec talks about a > DBUS interface, when becomes acceptable that implementations take the > org.freedesktop.foo bus name.. this is precisely why i want metadata in addition to the specs. we want specifications for services, configuration data, X11 conventions, etc., etc. to appear as soon as possible in a well known location so that as many people can be aware of them. if only specs with wider adoption can go into the repository, then we will continue to miss opportunities for colaboration as different groups work on their own little private magical sauce in places others are not aware of or check regularly. we _need_ a central place to track this growing cloud of documentation for "how we do things that could be and/or should be shared". using branches in the repository is a possibility, but then we end up with a forest of branches without any clear way to know, based just on the branches, which are of interest. i also think we also want to avoid conflict over what can be added based on who is supporting it or not. for these reasons, i do not believe that we can, or should, try to use the git repository alone as a way to "bless" specifications as being freedesktop.org standards. it should only be documentary and open to all specifications that have at least one open source project supporting it (drafting + implementation). with additional metadata for each specification, we can then conclude by a simple survey of adoption status, which specifications really are in practice broadly used and therefore candidates for things such as use of a freedesktop.org dbus name. the dbus names are an interesting point, in fact, since it is common to have a situation where only one implementation exists, but another project wants to use it increasing the number of projects interested in it. at that point, it may well be a good time to give it an org.freeesktop name on the bus. this would not work with any set of rules strict enough to keep things sane that only relies on repository existence. with metadata we can do things like register "interest with intent to implement in version $foo" which could then trigger org.freedesktop designation. iow, i think we ought to keep the issues of "is it a standard" and "is it documented" separate. imho, "is it documented" should be "it's been drafted, there's a working implementation out there, so it's in the repostory". "is it a standard" should be based on the metadata. the metadata brings many other benefits with it as well, such as allowing third party developers know which versions of which software become their minimmum dependencies given the specs they chose to use. (among others.) a permissive repository with procedures for documenting the specifications in the form of standardized metadata is just such an elegant solution for so many issues freedesktop.org faces. -- 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 Development Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg