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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel