Entries from November 2005 ↓

Finally took the time to redo the gtk+ packaging to be buildable directly from the code tree. The original Debian packaging contains the pristine upstream tarball and a set of patches to apply on top. This is of course fun to maintain as you have to update the packaging separately from the code, but it wasn’t (too) broken so… This setup makes sense when the patches are split by feature, but umm…

In the process I decided to cut down half the build time by removing the separate static build no one is using.

While trying to do the build outside the source directory (cd builddir && ../configure ...) I learned that gtk-doc or the way it’s currently set up for gtk+ rather sucks. Even in non-srcdir build files are built into the srcdir, except for those that end up in the builddir and fail to be found by gtk-doc or whatever. Can’t quite figure out why building the docs touches the (SGML) source files either. And FAQ and tutorial seem to built only during make dist.

Oh well, at least it builds now. And I didn’t see anything obviously wrong when testing it quickly in scratchbox. Minor version upgrades never broke anything, right? Sure… Need to get some serious testing done.

Old habits and processes die hard. While we’re working with open source (which is quite exceptional for a product) there’s still a long way to working like open source. Yes you can see the commits going into the repository, but the whole shebang is driven by internal processes using internal requirements, internal design documents, internal bugzilla, etc.

When you have a process that kind of works already, it’s hard to change to something new. We’re looking into making more technical documentation available after updating them and removing all naughty words first. Personally I’d like to see more planning and everything done in the open beforehand rather than after the IT-2006 release has been made, but that would be clashing with current policies. And we’re not entirely organized to truly handle outside involvement in bugzilla and mailing lists, it’s rather ad-hoc currently but we’re doing what we can.

Hope we get things sorted out sooner rather than later. I’m sure there are lots of areas where everyone would benefit from having more transparent processes. Especially comes to mind the Application Installer and what 3rd party applications can and can not do without resorting to binary patching framework components.

The work never ends. Though the devices are now shipping we didn’t close down and send everyone off for holidays, except for those sensible ones who went on to have their holidays anyway.

Bugfixing and optimisation work continues in the IT-2005 branch and eventually there’s going to be a new, better than ever, software update image made available. The gtk+ builtin stock icons will be there as we figured a nicer way to implement the memory savings. It just took longer and turned out to require additional changes elsewhere.

In related news Matthias Clasen took note of our optimisation effort and turned the builtin stock icons into a builtin icon cache, saving much of the memory overhead even if you do use the icons. It’s a big and untested change so we won’t be using it this time around. (Our change is much more localised, but works only if you don’t try to use the icons, which happens to work for all the 770 apps.)

In the meantime we’ve had Imendians bravely dig into the codebase and merge in all the changes from the gtk+ 2.6 branch. Subversion trunk is now up to the latest release, gtk+ 2.6.10. We’ll be sticking with gtk+ 2.6 for now as 2.8 and/or cairo are a tad slow in their current state. OTOH there are some nice things in newer releases and CVS HEAD we’ll consider cherry picking; icon data cache, stock icon cache, new g_sliced_bread memory allocator in glib, and other miscellaneous optimisations and bugfixes.

There’s also work ongoing to get our massive patch for gtk+ digested, split up in manageable pieces and committed upstream. Current status is being tracked in the Maemo Wiki.