Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism

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.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]