shooting the pipe

We have a pipeline for Plasma development: if it's an obvious fix/improvement, we commit and rely on post-commit peer review; if it's a manageable patch (no more than a few hundred lines of code) to a core component, we post it on the review board for comment; if it's a huge set of changes, use a branch; if it's a new plugin (plasmoid, runner, dataengine, scriptengine, wallpaper, etc) then start it in playground, move it to kdereview when it's ready and finally to either kdebase or kdeplasma-addons.

Leading up to the 4.0 release when everything was in a mad rush, and then briefly after 4.0 as well, we had an "open trunk/" policy. It was often pretty disastrous and I'd lose whole days to sorting the problems out.

These days patches and plugins alike appear fairly constantly, usually with little or no notice, outside of trunk/. It's a great feature, as it lets people experiment freely without having to worry about destabilizing things or having to get people to validate their ideas before having code to show. It's not uncommon to see a Plasmoid be forked and worked on in the playground with a few fundamental changes to the design of it, sometimes resulting in failure but often in something better than what was started with. The freedom that the playground offers is vital.

(This is not a unique-to-Plasma development style, of course.)

The main challenge for me is keeping up with it all: Right now in kdereview we have two Runners, six Plasmoids, two DataEngines and one ScriptEngine (update: it just got moved to kdebase) under inspection. These should all end up in 4.2.0.

I spent part of today and yesterday going through the Plasmoids in our playground area and have so far come up with six candidates for immediate movement to kdereview, three that should be prioritized for completion (due to the important nature of the feature they provide) and two more that are likely candidates for 4.2 (but aren't there yet). There's another nine that are similarly close and could all be moved to completion with a bit more effort. There are five plasmoids and a handful of scripting examples that will likely form the basis for a set of "How To" examples. There are another 17 I have yet to look at and five that I've just deferred examination on.

And that's just Plasmoids. I still have to take a run through the DataEngines, Runners, ScriptEngines and Wallpapers in playground to complete this round of shooting the development pipeline.

The effort is more than worth it, though, as others have put tons of their time and effort into these additions, and it is these additions which both validate, test and bring user perceivable value to the infrastructure beneath them.

What I do find interesting in going through a lot of these plugins is that when putting finishing touches on things I'm usually removing code and letting the underlying frameworks do more of the work. People tend to create things with a bit more complexity than necessary, and it's fun to watch how as we careful tend to central API like libplasma how the code on the edges shrinks.

When creating a clock, only the code necessary for a clock itself should be present.

I'm really excited about the set of examples, though, as we'll finally have a nice set of simple, clean, clear and self-contained bits of code to demonstrate various techniques in Plasma.

Anyways .. this is a mostly content free blog entry, I know. But whenever I get to poke my head out of the framework code and into the plugins other people are writing I get all giddy. ;)