.. 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 ..