messaging-indicator in kdereview?

[Aaron J. Seigo]

On November 26, 2009, Jonathan Riddell wrote:
> On Tue, Nov 24, 2009 at 05:49:22PM +0100, Sebastian K?gler wrote:
> > It seems there's a messaging indicator applet in kdereview since the
> > start of November. It doesn't build however (with karmic's packaged
> > libindicate-qt) and didn't get any non-scripty activity in more than two
> > months. Also, it's built unconditionally, even if its dependency
> > (libindicate-qt) isn't there, another breakage. Feature freeze is
> > looming, and I've not seen it proposed for review or at least a build
> > fix.
> >
> > I'd suggest to remove it from kdereview.
> 
> It was proposed a while ago but rejected because it doesn't use the
> new systray/notifier item spec (a shame the spec dosen't make it clear
> that this is an intended use). 

a protocol specification should not indicate all possible uses. that steps 
outside what a protocol specification does and gets into application-of-the-
technology territory. the intent of the spec is to allow for both known and 
unforeseen application of status notification, so it's really unreasonable to 
expect such things in the spec itself as it would be instantly limiting 
(besides being off topic). it would be like describing how a webbrowser's tabs 
and location bar should look like in the html spec ;)

now, that said, i did, *repeatedly* communicate this aspect of the technology 
to people who were working on this code at Canonical. so the "it's a shame.." 
thing feels pretty unfair. it wasn't a secret, it was just impossible to get 
it heard through the iron curtain of Ayatana.

i also don't believe that had this been spelled out in the spec that it would 
have changed what happened in the least. there was already a decided upon 
path, and i've discovered through years of watching that those decisions are 
ultimately unflexible. i understand this is a tradeoff made for project 
control and release marketing reliability.

> It's still a
> great deal better than what's in KDE currently

the UI is nice, the idea is good, the implementation is, tbh, ungreat. our 
shared users will suffer as a consequence. i looked at the code and had this 
been developed openly with upstream coordination, i would have offered 
feedback on it that would have highlighted a few issues. but if a group 
doesn't play by the rules of the game, i refuse to play the game with them at 
all. this is not petty, btw, it's protecting the value of the commons. i will 
not offer feedback on efforts that subvert the established process, no matter 
how good an idea it represents in the moment. the long term consequences of 
separate silos, non-open-consensus development and downstream fracturing are 
simply too severe.

now, i really dislike treating an ally like that, but i simply can't abide the 
behaviour. it is not welcome here and it will never be welcome here. were that 
to continue, your would become increasingly isolated in your efforts and while 
pushing on with your self-grown agenda we would compete for developers. given 
project Timelord, i don't think that aligns with your goals at all.

that's the crappy doom, but here's the happy glow:

the recent meeting we had about using status notifier spec in Ubuntu's gnome 
and working on integrating dbusmenu into both KDE and GNOME's implementations 
is a great step towards playing by the rules of the commons. it's consensus in 
action, it's getting needs met, it's communicating and coordinating our plans. 
i'm really, really hopeful that's the way it continues and currently am 
committed to supporting those movements. let's try to ensure that those sorts 
of efforts are what the Kubuntu - KDE relationship are characterized by going 
forward.

let's make that the reality and not accept anything less.

(interestingly, i recently came across some academic literature via a friend 
that documents how societies with successful long term commons often have 
ultra-strong us-and-them, in-and-out boundaries with very real consequences 
for those on the other side of them.)

> and continues to
> be developed as a standalone project with support upstream in KMail and
>  Quassel now.

personally, i find such ad-hoc-additions-to-upstream to be absolutely 
repugnant. it's not a sustainable development model because we have so many 
actors who would 'innovate' and if we chase after every cool cat that comes 
into the neighbourhood our software is going to become riddled with things 
that have no consensus support and which in many cases will fade away.

yes, yes, yes, i know, consensus is hard to get. but it prevents most 
(granted, not all) fuck ups. if you look at the majority of really big fuck 
ups in the last few years on the Linux desktop, it's been when some cowboy 
somewhere or another decides "this is the way to go!" without any consensus 
generation outside his little circle of BFFs and often in direct opposition to 
the general consensus. there are a few people in this world who can get away 
with that kind of behaviour because they are just that good/lucky. most of us 
are not those people and shouldn't pretend otherwise.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20091126/1b9b37f7/attachment-0001.sig