Thorsten’s Weblog

Being honoured with having a session at the OpenSuSE Helping Hands, I faced the problem of creating a screencast under Linux. Considering the load of vnc-based solutions inherently un-sexy, I tried istanbul and recordmydesktop - with the latter appealing to my knack for command-line utils (an extra requirement was no-hassles support for the very nice USB headset MMX2, which recordmydesktop’s “-device” option solved quite nicely).

So without further ado, here’s the recordmydesktop v0.3.7.3 cmd line I used:

recordmydesktop -delay 2 -device hw:1,0 --on-the-fly-encoding -s_quality 1 -width 1024 -height 768 --quick-subsampling --overwrite -o "path_to_ogg_file"

Of course the device option can either be ommitted, or needs to be adapted, depending on your local alsa setup. Recording starts after two seconds, when you’re done with your ramblings, press Alt-Ctrl-S. Some results of me doing screencasts can be found here.

With some 7 million lines of code (depending on how you count it), mostly c++, OOo is extremely challenging for everybody starting to hack on it. There’s a set of excellent tutorials on building, debugging & hacking on OOo - alas, and the end of the day, smooth coding requires thorough understanding of the inner workings and functional dependencies - in short, the design of OOo. I guess that’s where our documentation story is still lacking (with some notable exceptions, e.g. the API developer’s guide, or the UNO subsystem documentation). The problem with good (design) documentation is that it’s

• hard to write
• tedious to keep up-to-date (in fact, I believe most static source code documentation is always at least partially outdated)

To somewhat fill this gap (and avoid the staleness issue), I’ve setup doxygen-autogenerated source code documentation at go-oo. As of now, this is only a partial set of modules (because of runtime and space constraints) - feel free to drop me a note if your favorite module is missing.

Two examples for auto-generated inheritance graphs:

Feeling somewhat challenged by the other Thorsten’s comments that “some groups in the community say, these [processes] hinder the contribution to the project”, I cannot but present a slightly different view on that topic.

OOo was using child workspaces already for 2.0, so this is not a discriminating factor, and neither is valgrind (which was also in use before - and on top of that, focused fixing of valgrind issues resulted in a total of 35 issues fixed, versus 41 issues still open).

Leaves warning free code and crash reports - the former is all about defect prevention (from personal experience, actually making the code warning free did result in fixing a few serious bugs, but most of them were minor issues - the benefits come afterwards). The latter is about fixing issues after OOo has been released to the general public, and is indeed a great tool - but it does not explain why the numbers of new issues has been kept consistently lower than for 2.0 (if that’s not obvious: something must have changed before releasing the code).

So, my explanation for the significant differences between 2.0 and 3.0 would be

• introduction of some defect prevention measures
• but most importantly: taking the pressure off of the hackers to finish features at a certain point in time

This was achieved via a so-called train model, having frequent feature releases instead of 24-month big-bang style development. Needless to say that this style is standard for almost every opensource development. And coming back to the opening paragraph, I do believe that certain processes in place at vanilla OOo hinder community contributions - I’m talking about code contribution here, and I see a significant difference between contributions of part-time hackers to ooo-build, in comparison to vanilla OOo. The question is, what’s the focus of the project (community? the product?) - and, which of those processes have significant influence on quality and which don’t (and which can be replaced by other, similarly effective measures, that are more hacker-friendly).

Does this sound familiar: there’s a ton of stuff to do, which people put on a list. Every day, things from the top of the list get done, and other things are added to the bottom of the list. Usually, these lists are sorted for priority - which means, if there are enough high-priority tasks coming in, (almost) all lower-prio tasks will suffer from starvation.

For OOo, the list is IssueZilla, and the starving low-prio tasks are affectionally named “OOo later” - that name has the nice property of being eternally correct, as later usually never comes…

My conjecture would be that about every bugtracker in this world has those issues - annoying, but never important enough to be fixed for the upcoming release (but surely for the one after that…). At least it’s the same for Novell’s bugzilla. What’s the computer scientist’s answer to this class of problems: fair queuing - partition the input into priority classes, and assign each class an own queue and a minimal fraction of the resource-to-be-scheduled. This ensures members of each class at least minimal progress, and prevents starvation (at the cost of limited throughput for the highest priority class, of course).

So, well, that’s what we did here at Novell: we set aside a fixed fraction of time for Project Pedigree, which was all about fixing those small, but very annoying issues that our internal users have reported over time (or even reported for the first time - we went around and asked them about their favorite pet peeve). Smart idea, and I really enjoyed touching application code again - in fact, the work was quite similar to the very focused bi-weekly iterations I did during the agile experiment at Sun, as there have been (almost) no interruptions.

I’m currently wrapping up the Impress part of the Pedigree project, stay tuned for the list of things achieved.

Most of the external header guards now removed from the OOo source tree.