Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
- From: Lennart Poettering <mztabzr 0pointer de>
- To: Sebastien Bacher <seb128 ubuntu com>
- Cc: desktop-devel-list gnome org
- Subject: Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
- Date: Fri, 20 Jan 2012 23:08:43 +0100
On Fri, 20.01.12 15:06, Sebastien Bacher (seb128 ubuntu com) wrote:
>
> Le 20/01/2012 13:00, Olav Vitters a écrit :
> >It is called systemd, and it is NOT a dependency. What we depend on is
> >a few simple dbus APIs. If an OS doesn't implement those APIs, certain
> >functionality won't work. These APIs have been implemented in systemd,
> >but they can (and are being) implemented elsewhere.
> >
> >What I've said above is nothing new btw (to me). It has been discussed
> >openly, think on this mailing list.
> >
> >What I am suggesting now is that we clearly document this (depend on the
> >API being implemented).
> Hi,
>
> Ok, so as a distributor of GNOME I think that what we (Ubuntu) would
> like to see:
> - some public list of what services GNOME rely on to be fully working
> - some public announce earlier in the cycle, or if possible one
> cycle in advance of what API will need to be provided for the next
> GNOME release to be fully working
> - some details (spec?) about the API used for those who want to
> implement compatible ones
>
> It's fine to be using new services but if GNOME wants distributors
> to provide a good GNOME experience system requirements should be
> announced in advances with a clear description of the protocol to
> give enough time to integrators to work on providing those services.
You know, your complaining would be a bit more believable if Google
wouldn't find this for us:
https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-systemd-packagekit
So, the problem set has been known for a while, a number of Canonical
desktop team members have been subscribed to that page, the
documentation for the interfaces is all available, some code has already
been written by Canonical. So I really don't see what went wrong here,
except maybe that Canonical's internal communication didn't work out so
well?
Lennart
--
Lennart Poettering - Red Hat, Inc.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]