8000 commits

ohloh reckons that this week the count of commits in LibreOffice belonging to me hit 8000 accumulated over last approx 12 years.

I thought I’d sample each per-thousand rollover to see what they were…

Commit 8000: A minor startup time improvement and code simplication
Commit 7000: fix dnd crash. Generic bug fixing of fdo#39950
Commit 6000: callcatcher: remove unused code. Removing a few hunks of code that get compiled into the product, but that nothing calls. Some of the callcatcher foo which we use to trim the fat off LibreOffice
Commit 5000: Generic bug-fixing from grovelling over abrt traces, rhbz#710004 band-aid for immediate crash in IsAlignPossible.
Commit 4000: Workaround a weird-ass warning. from a minor compiler bug gcc#47679.
Commit 3000: Fix BSD uno bridges. We merged the various uno bridges together for the various unix platforms that use gcc to reduce the burden of maintaining so many. So needed to add the little register return quirk of the BSD platforms.
Commit 2000: Silence the (then) new gcc 4.5 warnings in our code
Commit 1000: Documented FSPA anchor values should override escher attributes when different. Efforts to get object positioning right on .doc import
Commit 1: MSOffice Controls {Im|Ex}port. Apparently my first post-StarOffice commit. Getting those “OCX” controls imported from MSOffice file formats.

Does this mean I’m an awesomely productive coder versus everybody else ? Nah, not really. For one thing, we started off with CVS went through mercurial and end up with git, and there’s generally a lot of difference in how many commits you generate with commit-unfriendly CVS vs git which makes you commit gung ho.

And there’s differences in commit style from one person to another too of course. I tend to generate a lot of commits because I like to refactor and code in “see my train of thought so you (ok me when I have to revisit it) can see where I went wrong if I do” steps rather than dump in a single commit that affects a hundred interconnected things. But it’s all the same amount of code at the end of the day.

Another wrinkle is that various development rules ended up hiding the true ownership of a lot of older commits. e.g.
a) Per day-0-release commits were all flattened of course, I only worked on StarOffice a short while before that event, so that’s a fairly small amount for me. But presumably a truly frightening number of commits for e.g. jp
b) for a while we worked by commiting only to cvs branches which release engineering would merge into master, e.g. this commit is an example, which is why the Hamburg release engineers hold unbeatable commit rates
c) And later the burden of commiting to OpenOffice.org for non Sun staff became almost impossible to bear, e.g. provide install sets for Windows and Linux, get a QA volunteer to QA the install set for you and sign off on it. Which was all pretty hard to do given the speed of the one or two windows buildbots available for the purpose and the limited number of QA people. Much easier to just dump the patch into bugzilla and see if someone inside the bunker could take care of all that for you, e.g. commits like this

Syndicated 2012-05-20 20:12:33 from Caolan McNamara

shiny langtag library

liblangtag looks very nice. I wonder if there’s anything in my abandonware localehelper that might be useful to stuff in there. Maybe some of the locale to langtag mapping stuff.

Syndicated 2012-03-13 13:15:34 from Caolan McNamara

libreoffice help ported to clucene

From the things that make me happy department. Years ago our help documentation source was parsed with a bunch of java tools. At the time gcj was the only possibility for us in RHEL/Fedora and the build time for all localized langpacks that we included was about 26 hours in our build system.

Which was a bit depressing.

So I rewrote it in c++, taking super care to keep the same JavaHelp-derived format and so forth. Which brought build times down to about 10 hours.

Which made me happy.

At some stage though, then it was decided to then index our help with lucene, which brought back java as a build-time and run-time dependency for building help and searching it at run-time.

Which made me sad again, though openjdk was the default for us at this stage, so it wasn’t as much of a pain, though that’s why you have that perceptual lag when you first search for a term in help.

But now, for LibreOffice 3.6, Gert van Valkenhoef has ported our lucene code to clucene. helpcontent builds faster, and there’s no lag on searching for something in help.

Which made me happy.

Distro’s that want to use –with-system-clucene will need to build and install clucene’s contribs-lib

Syndicated 2012-03-08 12:21:41 from Caolan McNamara

cross-compiling LibreOffice for windows (mingw32) under Fedora

Dave Tardon’s new howto cross-compile LibreOffice under Fedora to target mingw32 under Fedora, http://dtardon.fedorapeople.org/mingw/

Syndicated 2012-03-06 11:55:37 from Caolan McNamara

syncfonts is handy

When debugging font related stuff its typical that the problem can only be triggered by a specific set of fonts. Here’s a rough-and-ready syncfonts script which when given the output of fc-list -v will try and install the fonts that are missing and remove the extraenous ones via yum, which works for the common case

Syndicated 2012-02-29 14:49:49 from Caolan McNamara