that's one big avacado.

Tonight I made up some guacamole. I love the stuff. MMmmmmMMmm avocado goodness. In went one yellow and one red tomato, freshly squeezed lemon juice, finely diced garlic, diced white onion, a couple of finely diced red chilies, a little cumin, basil, sea salt and fresh ground pepper to taste. (Yes, no cilantro; I got out of the habit of using cilantro when P's mom, who hates the stuff, and I lived together.) In the large metal bowl I used for these things, I mashed it all up with a fork. I use a fork instead of the blender or other puree-er of food as I like my guacamole to have some texture. So nothing very out of the ordinary ... except the avocado.

I usually use 2-4 avacados, depending on whether I'm making a little bit of gauc for myself or enough for a bunch of guests. But tonight I only used one avacado. Despite using just one avacado, the mixing bowl is full and the proportion of avocado to other ingredient is perfect. This was managed because I purchased an extra large avocado. That's what the sign said, and they weren't joking: these things are massive. When P and I saw the bin of them in the grocery we just had to get one. There was probably somewhere between 4-6 avocados worth of fruit in this one extra large avocado.

The flavour is great, too, as I "had" to try some while making it to ensure a proper mix. =) It tastes just like any other avocado, it was wonderously, perhaps even a bit absurdly, large. And that humoured me for some reason. Perhaps I'm easily amused, after all. ;)

The guac is currently sitting in the fridge letting the flavours permeate the avacado mash fully. In a couple of hours I'll pull it out and wage battle against this extra large avocado goodness with a bag of tortilla chips. =)

Oh, and I finally downloaded the video from yesterday's KDE video cast and I'll be putting up a torrent for it tomorrow. Sorry for the delay, it was just a busier weekend than I anticipated. I'll post a link in my blog when the torrent goes live. Unlike the avocado, however, it will only be regular size.

Read More

Break even weeks on bugs.kde.org!

KDE developers around the world: we're currently just 14 closed bug reports away from a break even week! As of right now 475 bugs have been opened in the last 7 days, and people have resolved 461 reports.

I'd love to see KDE 4.2 get released with bugs.kde.org hosting less than 17,000 open reports and the only way to get there is to turn those status columns green!

Last week we delivered a crushing blow with twice as many closed as opened. If one removes the mass resolution of the 300+ aRts bugs with UNMAINTAINED, we were still 200 or so reports in the positive side of the ledger when Saturday rolled around.

Obviously, we won't have quite such a dramatic showing this week, but let's at least not lose ground after we've done so well recently.

Here's towards a better, slightly more perfect KDE 4.2.0! =)

Read More

KDE Videocast Episode 3, November 29!

Episode 3 of my KDE videocast will be broadcast live at 17:00 UTC on Saturday, November 29nd over at UStream.

This week's show will look like this:

• Hello, viewers!


• Week in review: KDE 4.2 Beta 1, Gran Canaria Desktop Summit and a developer activity recap.


• The Headline: The realities of meeting modern user needs, or "Why do Amarok and Akonadi use MySQL?"


• Feature of the Week: It's a two-fer! Migrating to Akonadi using kres-migrator and finding places with Marble's new search capabilities.


• Town Hall: Bring your questions to #aseigo on irc.freenode.net, or leave one in the comment section below if you can't show up! I'll have my sack of answers at the ready at showtime.


• Developer Corner: Using Phonon to add rich media support easily to your application.

A non-flv version with all the media and text files used in the show will be offered via bittorrent after the show so you can download it for offline viewing, in addition to the usual online clip at UStream. The torrent will also have the files provided individually this time versus the (bad idea) of a single archive.

See you there tomorrow!

Read More

abi checkers

Do you know of a tool that runs on Linux, preferably is FOSS, and can compare the ABI of two C++ libraries? If so, leave a link for me in the comments! =)

Read More

on my other perspective

I didn't mention it in my last blog entry on supppy chains because .. well .. it's not anything I can really say much about at this time, but: I'm currently spending some time consulting to a commercial project where one of the integral components is based on a Linux distribution. (Holy crap, how is that for vague?)

So for a good part of my days over the last while, I've had the experience of being downstream from KDE as well as the distributions who are KDE's downstreams. Some days it feels like I'm in a mobius loop as I shift positions in the production sequence. =)

It's been nice to be able to hold that perspective for extended periods of time, though. Being downstream (once removed!) from KDE (and the rest of the stack) is a rather different experience and mindset from being upstream to a distro. That's probably stating the obvious, but it's certainly another part of what has gotten me thinking about these issues more deeply.

Holding both experiences concurrently has given me the context to do things like explore negotiating with myself, role playing both sides of the conversation. (I don't actually self-negotiate when it comes to the real-world work issues; this is more a "mental exercises for hot showers" type material.)

More practically, I have to apply my goals and needs as a downstream without prejudice because I have a team that relies on and demands that; in a different point of the week (or sometimes the same day, even) I have to apply my goals and needs as an upstream without prejudice because, well, I have a team that relies on and demands that.

It is said that you can not slave for two masters, and at first I thought I'd run into issues with this until I realized that my master for whom I slave is one and the same: Free software. I just get to play the role of two different servants whose work must dovetail.

Given that these "supply chain" issues are kicking my ass in both of my servant roles, it's become something of an un-ignorable burning itch. Like athletes foot, or jock itch. Yeah, not pleasant.

I do also want to give a positive example (that I personally had nothing to do with) to show that this up/down coordination can work out well. The challenge was that a KDE4 user interface to network manager was needed.

Preferably it would be an improvement over the KDE3 one and it should work with the latest, greatest network manager stuff. Now, network manager is "upstream" to KDE and the distributions who really, really want this are downstream from us. Along comes Novell, one of our downstreams, and they say, "We really need both a better KDE network manager GUI for OpenSuse and it needs to use KDE4 libraries." They (Will Stephenson being huge in this role) start working on it. That work goes into the upstream repository while it is worked on, thus building a partnership through shared infrastructure.

Unfortunately KDE 4.2 goes into feature freeze before the network manager interface is ready. So people talk about it and determine that it could be in shape by the time 4.2.0 comes out, it just can't be part of the 4.2.0 release proper. OpenSuse could then ship this thing with their KDE4 packages even though it's not actually released via upstream yet. Sebastian Kugler, an "upstream" Plasma developer, starts pitching in to help make it happen. Everyone is informed and comfortable with the situation.

It seems to be working out well, but what happened differently here?

People along different parts of the production/supply chain got together and coordinated. Needs were communicated upwards in advance of crunch-time, and a coordinated effort emerged. Upstream was given a heads up about the inclusion of a non-released component that is just That Important(tm), and upstream actually got involved and puts resources on it to help ensure success. Upstream's happy because they get help from a much needed component from downstream, downstream's happy because they fill a need.

It's not a perfect world (perfect would have been inclusion with 4.2.0, or heck, even 4.0 if we really want to go for Perfect(tm)), but it's close enough (they are still using the KDE3 network manager in the meantime) and everyone is informed and comfortable with the plans. Needles to say, the user wins across the board and nobody is losing.

This all seems common sense, doesn't it?

Yet it is a much rarer occurrence in the FOSS desktop world than it ought to be. We are often chasing our upstreams, who are often running off on their own tangent, while we're doing the same thing to our downstreams. Every so often someone screws the upstream over because they don't feel they have a better choice, and the upstream gets miffed. All perfectly logical, but not very brilliant.

So why did common sense prevail in this case? In part because Will, Sebas and the Plasma team all know each other and get along. We talk often, have shared values and open lines of communication. Obviously this is not an easy dynamic to replicate.

So we know that with agreeable circumstances it can work out. We know that release schedules don't need to get in the way even if they don't line up perfectly. We know that resource allocation can be modified in response to voiced need. We know that different points in the chain can work together as if we were actually coordinated in some logical fashion. We do not have to guess at the plasusibility of it, then, we just need to figure out how to replicate the phenomenon.

What we are (or at least I am) missing are sure-fire ways to replicate these results when:

• We don't all know each other, or know each other very well


• We aren't in constant, regular communication with each other


• We rely on each other for different pieces of the puzzle


• We have independent bodies setting each group's agenda/roadmap


• The topic isn't always as limited and focussed as "an interface for the user to activate a network connection".

And it all needs to fit into 40-60 hours a week. Cue the Mission Impossible theme song? =) It may sound like it when it's put that way, but I have faith that we can construct an 80% solution that will blow away our current 20%-because-we-get-lucky track record.

Read More

free software supply chains

Over the past few months I've been quietly tracking our upstream and downstream interactions. The motivation for this has been my experience with the KDE 4 series, in which we have both been on more people's radar (when was the last time NVidia mentioned KDE 3 in a driver release?) and seen more trainwrecks both up- and down-stream from us.

In particular, the "distribution backporting" issue has really gotten out of hand. It's no longer just individual unbaked features that are being backported and shipped with stable KDE releases, but now entire applications are being pulled from pre-beta SVN and shipped with stable KDE releases. I know of two different applications this has now happened to.

Just as disturbing, some downtreams feel that they have the right to speak for us as an upstream to their communities and have, by doing so, misled people and abused KDE's relationship with users in doing so.

Of course, I'm still reeling from the issues Plasma has run into all across the X.org and Qt map. Features those projects have advertised, in some cases for years, simply were not mature or tested until we showed up and found out the hard way by running headlong into pointy skewers of buggy or simply featureless code bases which got that way due to not having real world applications at the ready to tease them into shape.

The losers in this are all around: users get sub-par product, KDE's relationships are damaged both with users and downstreams, upstreams look incompetent when really they just got caught out unawares and downstreams provide a muddled experience in their delivery phases.

This is not a healthy situation. I hope that's stating the obvious and that we're all in agreement thus far.

Note that I haven't really said anything about who's to blame for this. Take the case of lacking real world applications to test our frameworks with: who is at fault? Should KDE have been there earlier pushing on these areas back when these features were first being trialed? Should those writing these frameworks have ensured there were real world type applications doing meaningful things with their new fangled hotness before claiming stability and maturity? Not easy questions, are they? Personally, I'm not one for fingerpointing unless you really get it obviously wrong after having had a workable solution pointed out to you. We aren't at that point, however, with nearly any of the above.

While tracking these issues and trying to make heads and tails of them, often with great frustration draped across my brow, I have also been looking for analogs elsewhere. Most problems have already been at least identified, and most problems that have been identified have a history of attempted solutions. Just because I haven't had to deal with a particular problem first hand doesn't mean someone else hasn't, and so I've been searching for solutions (good or bad) elsewhere.

In talking with some of our downstreams, I've found it increasingly useful to talk about things in terms of supply chains and the kinds of relationships that end up forming around them. Unlike "traditional" software development where the supply chain is tightly managed and usually completely or nearly completely internal, the open source model seems to me to be a lot more like the free market dynamics seen in commodity markets and how supply trickles on through the machinery to eventually create products the consumer purchases. At least, that's been my impression. Feel free to correct me in the comments section of this blog entry. ;)

Mapping our current situation on to that of supply chain dyanmics does give us a well studied and highly optimized set of solutions that other people have already torn their hair, hearts and souls out over. So I'll be slowly edumecating myself about SCM (no, not that SCM, this SCM), something I'm only mildly versed in at best, and thinking about how to apply it sensibly, if at all possible, to improve our current state of affairs. It could be a dead end, but it could also be a source of inspiration. There's only one way to find out.

I'm devoting brain time to this because it is going to be increasingly critical to get our act together if we want to take on the next level of competition we face in the market without gutting our values and our resources. We have to communicate and coordinate much, much better between the different points in our software supply chain and get our roles correctly aligned with each other. Right now it's very ad-hoc and the network of people has grown beyond that which is sustainable based on a who-knows-who game masquerading as personal relationships.

I hope to meet with several of our partners at the Gran Canaria Desktop Summit in mid-2009 to discuss these things directly, and to have brought myself up to speed enough on the issues to be able to formulate and deploye systematic support solutions. If you have a great SCM book you think I should be reading in the next couple months, please comment below. I'm also wondering how I might gain access to the Supply Chain Council's full SCOR reference manual.

Read More

KDE Video Cast, Episode 2: Torrent it!

I got up early this morning so I could luxuriate in a hot shower, get dressed and go over my notes before the video cast this morning. It was an hour earlier and the second episode, so live attendance was down a fair amount: it peaked at "only" 194, which was 27 fewer than last week. I expected a spike on the first week (curiosity) and I knew shifting the time by an hour would suck as well. Oh well =)

I did, however, manage to figure out how to put text messages on the stream as well as videos hosted on Youtube. Unfortunately, these only show during the live broadcast and are not part of the resulting recorded version. I put a link to the show notes on the screen during the live broadcast thinking that would help people downloading it later, but ... fail. Additionally, UStream dropped out twice. My internet connection was fine (I was still in the chats), the server side just thunked out twice in a few minute span.

On the plus side the audio was better, I used a solid color backdrop, and the downloaded version is in mpeg format this week instead of flv's that won't work for anyone. Also included in the torrent are the show notes and the media I reference in the show, including a short Kopete screencast and a couple of JavaScript Plasmoids.

I am learning exactly what I want from a DIY broadcast software and am becoming increasingly tempted to see what Solid+Phonon in KDE 4.3 are capable of doing for me. For now, I just learn the quirks of what's available and soldier on improving each episode incrementally.

You can grab the torrent here and enjoy it at your leisure. Cheers! =)

Read More

Video Cast Episode 2, Nov 22nd!

This week's show will be one hour earlier than the usual schedule calls for: we'll be going live at 16:00 UTC on Saturday, November 22nd over at UStream.

This week's show will look like this:

• Hello, viewers!


• Week in review: KOffice beta, Amarok release candidate, bugs.kde.org improves and developer activity recap.


• The Headline: Entrepreneurial opportunities and the Free Software desktop: where is all the diversity?


• Feature of the Week: New MSN bling and graceful interfaces in Kopete


• Town Hall: Bring your questions to #aseigo on irc.freenode.net! I'll have my sack of answers at the ready.


• Developer Corner: Writing a Plasmoid in JavaScript.

An ogv will be available via bittorrent after the show so you can download it for offline viewing, in addition to the usual online clip at UStream.

As for why the bump up by an hour this week: There is a winter fair at the P-man's school on Saturday, and we'll be there for much of day. So I'll be broadcasting at 16:00 UTC instead. Apologies for the inconvenience, I hope you can still make it! We'll be back to the regular time next week.

Update: Due to popular demand metelliuscode's suggestion in the comments section, if you can't make the live broadcast for the Town Hall section but have a burning question to ask, leave it in the comments section of this blog entry and I'll pick one or two of the better ones to address during the Town Hall.

Read More

plasma systray, 4.2

So I've talked abut the system tray in 4.2 a few times recently, though mostly in passing. Today we hit a new milestone which marks the system tray area being feature complete for 4.2 (though not defect free .. yet!):

The white arrow on the edge is the expander: click on it and hidden icons show up. If you have no hidden system tray icons then the expander isn't shown.

You can see a progress meter for a file copy in there as well. Application jobs stack up there, as do system notifications. They automatically hide within reasonable times, are fully themable, support user interaction (such as pause, stop, resume, open, etc. buttons) and, since they are Extenders, can be detached and put elsewhere. This isn't limited to file operations, however: any application job can use this and in fact gets support for this for free when using KJob from libkdecore. Yes, that means even apps without a GUI can show their job progress in the system tray area! Possible uses? How about print progress, or K3B's burning status, or..?

The last icon on the right is pretty interesting as well. It means "you have some application jobs on the go or some system notifications available". Clicking on it hides or shows the list of jobs and notifications. We're using a generic computer or laptop icon (depending on whether it's a laptop or not) but still, we ought to have some more specific art done up for this use case. So it's a useful bit there: you can click it to hide long-running jobs so they don't endlessly bug you on the screen, and click it to get them back easily. But that's not the really interesting part. That icon is doing two pretty neat things in particular:

First, it's saying "put me at the end of the list, because I'm a special kind of entry". This marks the start of us starting to make the system tray experience richer, and we will eventually extend this kind of expressiveness to all KDE 4 system tray using applications.

Second, it's not "really" a system tray icon. At least not in the freedesktop.org sense. The system tray Plasmoid doesn't care though. It just sees it as another entry to manage like all the rest. Well, it can do a slightly better job with it because it's a native QGraphicsWidget, but it doesn't really know that either. It's more of a nice side effect of not using XEmbed in this case, but a set of D-Bus protocols instead: one for jobs and one for notifications. And yes, we've talked on the XDG list about both these systems for adoption as freedesktop.org specifications; the notifications one is based on the galago spec minus some "curiosities".

Now imagine if all the system tray icons were done similarly: not with XEmbed but over D-Bus. We wouldn't have to rewrite any part of the new system tray Plasmoid for that to work, we'd just add another SystemTray::Protocol to it and away it would go, happy as a clam. That is, in fact, precisely what we intend to do after KDE 4.2 is out.

This shows one of the strengths of Plasma that is born out of the purposeful design rules the entire team keeps in mind when we work on things: we write things to not be rewritten again in the future. We don't write really complicated stuff (that's how we can achieve such rapid growth in the number of components while not simultaneously exploding with instability), we just write things that are reasonably flexible. This prevents the "just tack on another room to the side of house" syndrome. We could have done something pretty similar with the D-Bus transition with the KDE3 system tray, but it would have been adding something to it that it wasn't written in mind for from the start. That way leads to head-meets-table-at-rapid-speed events, and having had enough of those already in my life, I try to help make sure we avoid more of them in the future.

What's really impressive is that the rest of the team Gets It(tm). As with many things in Plasma, the system tray was truly a team effort. Rob worked on the jobs integration, Dmitry worked on the notifications integration, Jason worked on the core design for the Plasmoid and took care of the X11 magic, I did the show/hide of hidden icons and lot of polishing work and Marco touched it with his usual graceful polishing wand here and there. I'm probably missing someone, too, as usual. =P

It is one of the bigger widgets, though, in terms of code. The Plasmoid itself is a little over 3,700 LOC and two DataEngines (reusable by others, of course =) were written for it: applicationjobs (336 LOC) and notifications (200 LOC). The freedesktop.org protocol implementation accounts for 1,105 lines of the widget. That's nearly twice the amount of code for the other three protocols combined (jobs, notifications and Plasmoids) and far, far more than twice as complex. The UI parts are are also pretty complex, though, given what it has to do and what it's meant to do in the future and currently weighs in at a hefty 1,294 lines. The core classes representing the concepts of Tasks and Protocols is the other 700 or so lines.

And there, in a nutshell, is more than you ever wanted to know about the new system tray Plasmoid.

Read More

.. and speaking of bugs

Speaking of bugs (in my last blog entry), we (the Plasma team) have a goal to have no more than 200 defect reports open for Plasma and its components when 4.2.0 hits. We're currently surfing at ~110,000 lines of code, with a ton of that being new in 4.2; that means a goal of approximately one report per 500 lines.

Update: I just realized I missed counting KRunner, libplasmaclock and libtaskmanager, which adds another 6,096 LOC to the total, bringing us close to the 120KLOC mark. If we added KRunner to it, we're at ~122KLOC; but that's a separate component when counting these bugs.

Another metric might be components: by my count we are shipping 100 plugins (I may have missed some, so it's at least 100), three libraries (libplasma in kdelibs; libtaskmanaer and libplasmaclock in workspace) and six apps (plasma desktop shell, plasma on screensaver, plasmapkg, the desktop theme customizer/creator, the data engine explorer and the plasmoid viewer). That's 109 discrete components meaning we're aiming for less than two reports per component, and some of those components are bigger than small.

We started at a dizzying 450+ reports about a week ago, but through careful triage and lots of commits we're already down to 294. There will be a flood of new reports with the betas that are about to come out and the bugs will get progressively more difficult to fix as we pick off the low-hanging fruit and get left with more NMBs (Nasty Monster Bugs).

The Plasma team seems to both value making things as high quality as we can given the various constraints we live within and enjoy destroying the beasties with a rather lovably mad passion. This makes me confident that we'll make our goal.

Now that we're into the feature freeze period, it's probably an idea for the KDE sub-projects to set themselves release goals. Whether it's bug counts, artwork finesse, performance benchmarks or whatever, goals can't hurt. If you do set such goals for your project, be sure to make them reasonable and clearly described to everyone on the team. This ensures that the goal will be shared and has a tangible end point that people can strive for. When the goal is met, everyone can enjoy the feeling of triumph. This is where team leadership is very useful, as an email to a list with a positive tone and a realistic set of metrics contained within can really help rev things up without burning people out in the process. =)

This is probably nothing new to most KDE (and coding) veterans, but I thought I'd mention it anyways. Happy hacking bug hunting ..

Read More

paddling upstream

Matt Rogers recently added UPSTREAM as a report resolution type on bugs.kde.org for us. I asked for this because a lot of issues in Plasma were the result of bugs elsewhere in the stack and I hated closing those reports as INVALID since they were not INVALID at all: they just weren't something we could do anything about in the Plasma code base.

Technically not all the bugs we close are really UPSTREAM, though. Some are DOWNSTREAM, namely the bugs caused by packaging foobars or poor backporting decision making and/or execution by OSVs (operating system vendors, aka "distributions" in the Linux realm). However, since we don't have DOWNSTREAM as an option we mark them all as UPSTREAM, noting where in the stack the problem really is in the comments section.

We've only had the UPSTREAM designation for a couple weeks now and already we've closed 19 reports in Plasma as such. That's probably about 10% of reports, which may sound high (and, well, it is) but it's actually a lot lower than it was.

First off, OSVs are actually getting better at packaging Plasma which is leading to fewer problems there. We're also making it easier on them by having fewer interesting Plasmoids in playground and keeping binary compatibility in libplasma while having a symbols check on plugin load (thanks to an upstream, actually; namely Dirk @ OpenSuse). I expect to see an uptick in this category, though, as we're already seeing reports coming in from packages being pushed out with half-baked backports.

Second contributing factor is that the graphics driver issues are actually getting sorted out bit by bit. The newest NVidia driver, for instance, actually works across the board with Plasma. Performance is great (even across multiple screens, apparently) and no artifacts to be seen. They aren't the only ones working successfully through issues, either, and so this area of UPSTREAM bugs is slowly but surefly declining.

Third, bugs in Qt are getting hammered out and fixed. Alexis Menard, who was a student of Kevin Ottens (explaining how he got involved with KDE in the first place =) and a Plasma hacker for the last year and a half or so is now working at Qt Software in Oslo and doing a great job of triaging issues Plasma reveals in QGraphicsView and elsewhere. So that source of UPSTREAM should also be diminishing in the coming months.

As much as it's fun to go "hey, that bug's not our fault! *CLOSE*" it really pains me to mark things as UPSTREAM because it means our software suffers due to bugs in other people's code that I don't work on and therefore have a limited ability to affect positive change in. Working around other people's bugs is sometimes possible .. but a matter of last resort, and completely off the table when it results in a worsened user experience.

For the last year we've really taken it in the proverbial ass over UPSTREAM issues, but it seems that the clouds are finally parting and the sun is shining through. 2009 may actually be a year in which the overwhelming majority of bugs filed against Plasma are actually our own screw ups. =)

Read More