On Fri, 2012-01-20 at 23:48 +0100, Lennart Poettering wrote: > On Fri, 20.01.12 16:29, Ted Gould (ted gould cx) wrote: > > On Fri, 2012-01-20 at 23:20 +0100, Lennart Poettering wrote: > > > On Fri, 20.01.12 08:59, Ted Gould (ted gould cx) wrote: > > > > It seems to me that this would be a good usage of Freedesktop. I'd be > > > > happy to maintain such a repository if people would be willing to use > > > > it. > > > > > > Yeah, it's a great use of fdo, and that's why I put it on fdo. > > > > Just to be clear, you'd be happy if the interfaces were moved to a > > different repository that was versioned independently of systemd? And > > then systemd could depend on a particular release of those interfaces. > > Honestly, I don't see why. The wiki is just fine. The interfaces are > versioned independently of systemd (that's why their interface names and > object paths contain version numbers (currently at "1"). And those > version numbers are specific to the API, and entirely unrelated to > systemd. It's basically how D-Bus versioning is generally accepted to > work). > > I already maintain a ton of stuff, and I try to keep maintenance burden > and bureaucracy small for myself. Hence the Wiki, and not a complex > standards process and a git repo. All API versioning we need should be > done within the D-Bus interface itself (where the right place is for it > anyway) and all documentation versioning by using the history > functionality of the wiki. I guess that I don't see that as adequate (hence why I suggested something more formal). One way that I had thought this could work on the Debian packaging side of things would be using the Requires/Provides labels in the package. So then something like systemd could provide "freedesktop-system-interfaces-45" and GNOME could require that. There could also be other providers and users who wanted to switch would then get their choice. Pulling the version number from the wiki for all the different interfaces would make that complex and burdensome to maintain for the packagers involved. Which is why I suggested something with a more stable and uniform release process. --Ted
Attachment:
signature.asc
Description: This is a digitally signed message part