Proposing the StatusNotifier specification
Aaron J. Seigo
aseigo at kde.org
Wed Jan 13 11:59:50 PST 2010
On January 13, 2010, you wrote:
> On Tue, 2010-01-12 at 10:13 -0800, Aaron J. Seigo wrote:
> > On January 12, 2010, Aurélien Gâteau wrote:
> > > I remember one of the outcomes of the freedesktop.org discussion we had
> > > at Gran Canaria Desktop Summit was that a spec didn't have to be fully
> > > finalized to be allowed to use the org.freedesktop DBus namespace.
> > personally, i think it needs to have at least significant "sign on" by
> > xdg projects. these kinds of conversations that are tentative, unsure
> > and spiral towards inconclusive results are precisely why i have
> > advocated the use of a metadata file in the repository.
> I agree with you 100% (may be even 110%) on the need for a file, and a
> process for how that file gets signed. I don't think that we have
> enough process for that today. I think that we need one, which
> basically amounts to bylaws of FD.o on specs.
Yep, and I've submitted such a proposal a few times to this list. There's a
git repo that goes along with it that has a README containing the proposal as
It's probably not perfect, and I'd love more feedback. Feedback that has
already been received has been merged into the proposal, and it has improved
due to that feedback. :)
> I think there are some unanswered questions:
> * Who can sign it? I think there should be some way for projects
> to designate who from their projects are the go-to people when
> looking for such signatures. In general, you could say the
> boards, but that's unlikely to be the right folks. I'm guessing
> technical standards aren't their expertise.
I think that's up to the projects involved. I know within KDE that we can
quite easily ensure that appropriate people (in the plural, it will be
different people depending on the topic) are involved and if they implement it
in KDE and get the support needed to do so from their fellow developers,
that's enough for KDE. This is really just basic project mechanics, and I'm
certain that GNOME is similarly mature enough as a project to do the same.
I don't think that there needs to be a formal registry anywhere, but people
who sign on, if they aren't known to others involved (and so their credibility
is assured as well), they should be able to provide support for their approval
of the spec (e.g. links to the project's relevant mailing list discussions or
links to the code already in their project's source code repository that will
be or already is part of an official release).
We could agonize over this issue and create a bureaucracy, but I believe we
can manage without one. If we do end up needing one (due to abuse) we can set
one up later as needed.
Does that sound sensible, or do you think I am being too optimistic? ;)
> * What votes are needed? Is an XFCE vote equivalent to a KDE
> vote? Do people classically categorized as "desktop
> customizers" (Maemo, Moblin, etc.) get their own votes or are
> they lumped in with GNOME in this case?
That's probably the biggest open question, and discussion was started but
never concluded (due to lack of involvement, actually). My thoughts are this:
Given that fd.o was started by KDE and GNOME and was an organization for those
two projects for all practical intents at the start, we could begin simple and
say "It needs the sign on off both KDE and GNOME to be recognized as
I don't think that's a useful long-term strategy, however, it's just something
that would allow us to start going.
There are other actors at the table here, and their interests should matter in
a concrete sense. That's the only way we can effectively grow this
organization, while showing projects the respect they deserve. So what might
I don't think, simply based on relevancy metrics, that having XFCE or LXDE
sign on would be the same as having KDE or GNOME sign on. Ditto for Maemo or
Moblin. As these projects grow in importance and entrench themselves as
meaningful players in this space, they could certainly be "promoted" upwards.
This means having a multi-tier (or even "just" two-tier) system where (at
least for now) we would look for "two out of three support" where KDE and
GNOME are both "one" and the other projects must come to consensus and "vote"
as a block. I would hope over time that this would grow and we'd have other
projects. join KDE and GNOME with a singular vote. How would that be decided?
We are not an industry group grappling for a choke hold on each other's
throats. I don't believe we need a bunch of rules and protections from each
other. When/if another project achieves a similar significance in this
particular arena (fd.o and the F/OSS client side space), I have no doubt that
KDE and GNOME would recognize that. It is in all of our best interests to work
together and ensure there is useful representation, and to ensure that happens
we need people around such as you and me to remind each of that as needed.
Executive summary time:
* KDE and GNOME each get one "vote", which is recorded as their approval in
the metadata file
* The other projects who work with fd.o would form a block representing a
third vote, and they'd have to work out consensus between themselves.
Individual projects would record their individual approval in the metadata
file so that consensus would be very evident as well.
Note that in the system I proposed, projects can also register than they
reject a given proposal. I've swayed between the idea of having a veto or not,
and I don't think it would be useful to do so, at least at the start, given
the complications it could create and given that it would be an edge case.
> I think that FD.o was started as a place for discussion, and we're
> finding that we need a little bit more than just a place for discussion.
> Different people seem to apply different weights to discussions here and
> the specs -- and we should be clearer about what they mean (both the
> discussions and the specs).
We also need to be clearer to those watching from the outside. Even when we
all agree internally, often that looks like complete chaos and uncertainty to
the outside. :)
> More on topic, I'm worried about having to ship code that implements
> StatusNotifier under "org.kde" and "org.ayatana" real-soon-now. And
> since we don't have answers to these questions, or a process, I'd hate
> to see this spec held back by something that doesn't exist.
I don't think the process that was proposed is heavy-weight, difficult or
So I'm going to make a brash suggestion: instead of waiting and allowing this
to be held up by those who do not have an opinion. do not wish to share, do
not have the time / energy to get involved, etc .. let's simply go ahead and
do this thing.
Marco has the spec draft in a branch of the git repo; one of us with commit
rights to the git repo simply needs to merge that branch with the mainline
KDE can quite easily sign off on the spec in the metadata file, we already are
shipping an implementation.
If GNOME (or a consensus of the other projects) can sign off on it as well
then we're "done" and can move on.
If anyone has a problem with this, they need to speak up. In fact, if you
think this makes sense, then I (or you can, if you wish :) will draft a "speak
now or forever hold your peace" email to this list proposing that we adopt
such a strategy and if there is no significant negatives, we simply "let the
people doing the work decide" and put this in place and fd.o will evolve.
(As for commit rights to the repo itself, anyone with formal ties to one of
the projects should be able to commit to it IMHO.)
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
More information about the xdg