Guadec has been in interesting conference, particularly because it took place in Istanbul this year. I tried to keep a few notes throughout the days to wrap up the experience and discussions here.

Sunday

Headed off for Istanbul, partial Imendio meet-up at the airport in Vienna, gathered remaining Imendians at the airport in Istanbul. Like many others, we stayed at the Golden Long Hotel near the seaside.

Monday

Kris and I met up with the Gnome release team where we summarized the Gtk+-3.0 ideas that have been cooked up during and after the Berlin Gtk+ Hackfest.

Tuesday

I was planning to attend the Maemo BOF in the morning, but shortly after arriving at the conference venue, Federico literally dragged me into the DVCS BOF. Still, I only managed to attend the second half of it which was almost exclusively about Bazaar features. People told me the first hour had been quite the contrary and focused mostly on Git hyping. Clearly, there was no consensus after the meeting on what the future versioning system in Gnome will be.
I’m not surprised that is the case. As things currently stand, SVN has very active development and user communities, Git is very actively developed, Bazaar is as well, as are a couple other VCSes. Active developer and user communities are generally a good sign for a healthy project and also an indicator for future relevance. Thus, in any larger community such as the Gnome community, it’s easy to find lots of critics and lots of supporters for each of the bigger versioning systems and that’s unlikely to change much. Consequently, there’ll not be an easy consensus on switching to a single versioning system any time soon, so I think the most productive approach for Gnome to take is to prepare the hosting of multiple VCSes, certainly SVN, Git and Bazaar. Needless to say that cross-VCS integration will also become increasingly important in the future, so focus on maturing and extending git-svn, bzr-svn, bzr-git and the like makes a lot of sense.

Later that day, we had a Gtk+ Developers meeting in the medium sized presentation room. The place was a bit too large to have the planned face to face discussions so we’ve had to sacrifice some of the spontaneity to microphone resource sharing. Kris took minutes during the meeting and will probably post those to gtk-devel-list once he’s found a minute to process them. The meeting was quite productive nevertheless, we discussed the upcoming Gtk+ 2.14, features and schedule for 2.16 and 3.0 and a bit of the post-3.0 road map.
Right after that discussion, Kris and I attended the advisory board meeting where we briefly wrapped up the developers meeting, the Gtk+ Hackfest in Berlin and the improvements the Gtk+ project has seen since the State of the Gtk+ Maintenance email. In particular, we stressed that we now have the GtkTasks and Gtk+ 3.0 Tasks wiki pages which can serve as an entry point for contributors and assistants to the project at various experience levels, in particular for companies that want to sponsor developer resources. Also for people that have an interest in long term Gtk+ project involvement, feel free to read up on how to become a Gtk+ maintainer.

Pizza looks weird in Istanbul BTW:

Wednesday

Almost by accident (I was mostly looking for an air conditioned hall in the afternoon), I happened to be watching “Gnome Documentation: A year in review” by Don Scorgie where he described the new user documentation tool Mallard. For some time now, I’ve been working on a Wiki syntax parser for Doxer to unify the markup I have to use for my blog, inline documentation and CMS content markup at testbit.eu. (I have a blog entry in the queue on this for another day.) In this context, implementing a Doxer markup backend that generates Mallard’s XML input could be an attractive markup alternative for future Gnome documentation – it at least ended up on my ever growing TODO list. ;)

Lots of people approached me throughout this and the following days for a chat about Gtk+-3.0 and what comes after that. With the merging of the GSEAL branch into upstream trunk recently, there’s been a lot of focus on the technical preparative work we’re doing for the actual 3.0 release which is planned as an ABI break to Gtk+-2.16 without adding any new features (it’s basically just a re-release with all deprecated code removed and current “private” API really made private by moving it to non-installed source files).

What has been lacking emphasis in this course is that 3.0 is going to be the necessary enabler, needed to work on implementing future visions of Gtk+ and to refactor the code base back to a healthy state where it becomes maintainable again. Quite expectedly, the need for the sealing and accompanied ABI break has been questioned several times, so I’ll reiterate the reasoning here:

• Everybody falls the first time.
  Code development in open source projects is very evolutionary, especially for projects that don’t clone or reimplement existing specified APIs like Libc. A whole chapter is spent on prototypes in The Mythical Man-Month:
  “Plan to throw one away; you will, anyhow.”
  So newly added components and APIs are almost certain to need fixups or revamps in future iterations (likely more than once). If critical internals are being exposed and eternal ABI stability has been promised, this however becomes impossible. Given the development history of Gtk+ and the variety of interests in this project, it is vital for its future success to prepare for future changes and allow iterative improvements. After all, progressive improvements, appreciation of contributions and adaptions to changing circumstances is where the free software development model shows its strength. The waterfall design model is not it.
• Gtk+-2.x is essentially a dead end.
  Everybody agrees that Gtk+-2.x is pretty much dead in a few revisions because of the huge work involved in its maintenance and no relief in sight with its current ABI maintenance policy. This is at least true for all current and past core team members (i.e. everyone who actively tried maintaining 2.x over a significant period). The question is whether we move to an entirely new toolkit (Clutter, Rapicorn, Qt, HippoCanvas, etc) or whether that “new” toolkit is Gtk+-3.0 which may be largely API compatible with Gtk+-2.x. In either case, applications and libraries will need to migrate to a new toolkit base with a different ABI, the main difference is the involved porting effort.
• GLib and Gtk+ do have a means to deal with API changes:
  1) We provide new alternative interfaces (functions).
  2) We deprecate old interfaces (functions) or provide compatibility code in old interfaces.
  Notably, this does only work for API that is exported via function symbols. Structure fields that are directly accessed from application code can’t be deprecated and removed without breaking ABI, and there is no compatibility code upstream could provide for these kind of accesses either. That’s why we want to move away from exposing any structure internals in 3.0 and beyond.
• 3.0 will ABI-incompatibly remove all deprecated and private APIs.
  Of course, the above described deprecation scheme only scales well if deprecated APIs are really removed from the code base at some point. Technically, this is an ABI break which is why GLib/Gtk+ have not been doing this since 2.0. However, lots of other vendors do this to keep a healthy code base, e.g. Qt does break ABI between major releases, Python 3.0 will be incompatible with 2.5, Apple does remove long deprecated APIs in newer releases of Mac OS X, Symbian broke API and ABI in 9.x, Microsoft broke behavior from .NET 1.1 to 2.0, and the list goes on…
  By exposing only function symbols as future public interfaces, we’ll be able to provide arbitrary compatibility functionality for old interfaces on top of new components, add helpful runtime warnings for iterative migration and constrain future ABI breaks to removal of properly deprecated interfaces.
• User visible gains are post-3.0 features:
  Since GLib and Gtk+ are largely volunteer contribution based projects, it’s close to impossible to plan exact arrival of future features. However the following is a list of things that have (partially) been discussed as post-3.0 work during the Gtk+ Hackfest already:
  • Full support of alpha transparency for all widgets;
  • Support for (partial) stacking of widgets (needs transparency);
  • Offering easier layouting facilities;
  • Support for animated visible transitions between widget states;
  • Providing new UI metaphors based on simulation of physical effects like acceleration, 3D browsing of image collections, 3D skimming through notebook pages, and more;
  • Using IDL based type data generators and code generators to improve the way widgets are implemented;
  • Implementing a new theming system for the toolkit;
  • Moving towards exposing widget features only via interfaces that have their own handle (asymmetric query_interface).

This is how GSEAL, the Gtk+-3.0 release and a couple remaining outstanding tasks are going to enable development of exciting future user visible features. The next step for Gtk+ to get work in visionary areas off the ground is to start consideration of feature feasibility and implementations, required resources and tentative schedules.

At the end of the day, we had the Opening Cocktails Party, during which I managed to catch Hallski tattooing J5:

Thursday

Thursdays most interesting event was of course the keynote by Kris which got hijacked by the Gnome release team for the announcement of Gnome 3.0 which is essentially Gnome 2.30 cleaned up and based on Gtk+-3.x. Kris’ slides are available online:

	http://people.imendio.com/kris/gtk-state-of-the-union-2008.pdf

The slides provide a good overview of what Gtk+-2.14 will bring, prospects for 2.16 and visions/requests from the community for Gtk+’s future. As previously described, Gtk+-3.0 is about enabling refactorings and development of new features, and the plan is to do our best to make the transition away from old deprecated code as easy as possible. Other than properly porting an existing Gtk+-2.x application to work with the G_DISABLE_DEPRECATED, GTK_DISABLE_DEPRECATED, GSEAL_ENABLE switches, no additional changes will be required to build and run an application on Gtk+-3.0.

At the end of the day, there was the boat trip through the Bosporous which provided a beautiful sight along the coast line.

Friday

I managed to attend the latter half of the lightning talks which was as always quite interesting. I should probably ignore my laziness and actually prepare short lightning talks for next year about Rapicorn and possibly Doxer… ;)

I took particular interest in Transifex, an online translation platform that can work together with multiple VCSes and that we’d ideally move all Gnome translations to in the future. There are two things I’d like to see fixed in a future translation workflow from a developer perspective:

• The .po templates should really be generated by the developers of the upstream project by automatic means, e.g.:
  make update-po -C po/
  So the upstream version of intltool and po/Makefile.* are used instead of possibly broken or outdated intltool/gettext versions on the translators system.
• Developers should be able to determine merge points for translations, and also review related non-po file changes, rather than having translators wildly commit into upstream repositories (which may conflict with other VCS workflows like branch merges or commits around release phases).

Later on, Federico presented his ideas for timeline tabs for the desktop. This should make it rather easy to find documents or URLs from previous days or weeks, because out of natural necessity, humans generally have good chronological associations. So the new and nice part about this approach is that it can provide good visual access to the chronologic dimension, something a file system doesn’t usually reveal easily, and that’s not easily made accessible by the most prominent desktop metaphors either.

I feel very tempted to start an implementation of the desktop tabs with Rapicorn, however with a few refinements of Federico’s proposal:

• The view should provide a “chronological zoom” slider to switch the view between years/months/weeks/days/hours.
• To be most useful, we’ll need a crawler that tries to (re-)construct past file modification history without relying on programs pushing journal entries about file edits. This will be needed anyway unless every program on this planet provides file editing journal information.
• I think the journaling hooks need to be implemented via DBus and not rely on Nautilus, so they’re usable by all cross-desktop applications and non-GUI programs.
• Various filters by file extensions, magic and possibly more will also be needed in the tab view (this was partly raised during the discussion phase at the end of the presentation).

Saturday

About half of the Imendians headed home on Saturday, we had some early leaves on Friday already and left some others in Istanbul for additional vacations.

Oh, and since I’ve been asked about my nickname here and there, I decided to add tabs to my hackergotchi for clarification:

Aftermath

There have been quite some discussions on the Gtk+-3.0 plan after Kris’ keynote. One thing that was brought up is that releasing an ABI incompatible but featureless new version of Gtk+ and calling it 3.0 is rather unconventional. An alternative scheme could involve releasing the ABI incompatible cleaned up version as 2.99.0, make 2.99.x the new development branch and release 3.0 with cleaned up ABI and new features (would have been 3.2 in the original plan).

Just like LinuxTag last year, I went to Berlin the past week to help running the Gnome booth for LinuxTag 2008.

Due to a sports accident, our booth bunny Sven Herzberg unfortunately couldn’t make it, so on Tuesday I took over booth management and merchandise from him and hurried to Berlin in an ICE instead of a car as was originally planned. In Berlin, I met up with Mathias Hasselmann who brought the European Gnome event box and together we set up the booth until late in the night.

On Wednesday morning, Michael Köchling and Christian Dywan arrived, so we had enough people to properly man the booth. Michael seems to be an early riser, since he managed to show up at 09:00 for all days, so i passed the booth keys on to him.

Around lunch time, I was dragged away for an interview about business involvement in free software and Gnome in particular by Malgorzata Ciesielska, a business school student from Copenhagen. She also interviewed other people like Lennart Poettering who also sporadically hung around our booth.

Later that day, Lennart and i went over the new libcanberra API in a lengthy discussion. Libcanberra is a new library for playback or activation of sound events in response to desktop actions that Lennart currently works on. We talked about the needs of timing information for some usage cases, possibly also dispatching forced feedback controls via the library and implementation of a Gtk+ module to hook canberra functionality up with GUI events. What turned out to be a bit tricky is to derive actual semantic information from the low level X event notification that Gtk+ signals proxy, such as dialog-confirmed, dialog-cancelled, menu-item-selected, menu-item-cancelled, combobox-popup, combobox-selected, combobox-cancelled, etc. This extraction requires significantly more logic and special casing of event notification than Lennart apparently had originally hoped for.

On Thursday I attended the Linux Kernel – Quo vadis? talk by Thomas Gleixner which was quite interesting. I managed to catch him afterwards to talk about the prospects of having a memory pressure signal in the Linux kernel. For GLib and Gtk+, this’d be quite useful to voluntarily release pixmap or GSlice caches, particularly desired on embedded platforms.

Friday I sat down with Vincent Untz for a very productive discussion about Gnome/Gtk+ release prospects, autotools, intltool features and more. Later I had a chance to chat with Alexander Neundorf about KDE’s recent CMake migration process. Overall, they seem to be pretty happy with the results. Major benefits from migrating from autotools to CMake seem to be:

• Build process speedups due to getting rid of libtool.
• Simplicity; the build setup is back to a manageable level again. For KDE, the previous combinatoric mess of autotools was hardly fully understood by any single person.
• Unification/merging of build files for Unixes and Windows. (Duplication of build logic between auto* files, nmake and MS project files is currently a major annoyance for Gtk+’s Win32 maintainers.)

On Saturday the last day of the conference, I attended Anne Østergaard’s presentation about Gnome Foundation structures and achievements, the slides of which are available here: The GNOME Foundation (PDF).

After that, I went to Jono Bacon’s talk in which he explained how the free software community is a creative and productive community, which sets it apart from other common community types in our society (usually fan communities). He went on pointing out how this collaborative and open community as a whole (and thus every significant contribution to it) impacts and gradually changes the really big IT companies from within in an unprecedented manner. Come to think of it, this is an incredible achievement that we should rejoice in, especially because it is a morally correct change in that it strives towards openness.

All in all, it was a nice conference again. Personally, I particularly enjoy meeting up with other hackers for productive face to face sync ups. So I’d like to thank Christian and especially Michael for their great efforts in patiently answering bypasser’s Gnome questions at the booth, while I wandered off to talks or had technical discussions in its back.

The Xen keynote was on Wednesday. Xen 3.0 comes with some interesting new features, it’ll introduce IO virtualization and supports new virtuallization technologies from Intel and AMD. One important lesson I took away from that session is that using virtualization aware drivers on the guest OS can boost performance from roughly 10% using generic virtualization techniques, to more than 90% of the ideal performance throughput (native host OS performance).
–
This day, there was also the ZODB3 talk. This is an object database which can be used completely independently from Zope, it provides a very nice interface in python to implement hierarchical object tree persistence, has ACID transactions with rollbacks and allows for doomed transactions. At the lower level it uses a stable subset of python’s pickle and supports multiple storage backends.

Thursday had a Linux forum where Thomas Gleixner discussed recent realtime work in the kernel. The low latency and preemption patches that went into the kernel over the 2.6.x series brought a number of positive side effects such as general responsiveness improvements on loaded systems and new debugging mechanisms. From the new debugging facilities and raised threading issue awareness amongst kernel developers, a good 1200 patches containing bug fixes and cleanups resulted. And development in this are has not come to a halt, current/future work includes getting rid of idle-state interrupts that do nothing by having a tick-less kernel that only wakes up every once in a while when actual work is due and cleaning up general jiffie dependent code in the kernel. Now what’s left to hope is that distributors get their act together and enable the low-latency preemption patches for their desktop kernels. The patches work, they are stable, and they provide a much better user experience. E.g. if you experience sluggish system behavior during crypto filesystem IO, or experience drop outs with your sound system/server, don’t blame it on the kernel people, blame it on your distribution not allowing time slice preemption.
–
The other talk I attended was held by Matthias Hopf about the Compiz+Beryl merger. The resulting effects he presented excited the crowd as usual, and then he talked some about ongoing developments like input event transformation. After the talk we had some more personal chatter about using the 32bit XRGB visual to add alpha channels to XWindows, and future X extensions to allow applications to notify the server about when to issue EXT_texture_from_pixmap (needed for flicker free composite support).

On Friday, Lennart gave a very good presentation on the state of PulseAudio. He described how it solves the vast majority of audio use cases and can in combination with libsydney finally put an end to the never-ending lack of a portable and usable audio API. Beyond the talk, Lennart and I used every spare minute during the LinuxTag days to discuss libsydneys new API. All in all, it looks like a suitable candidate to replace (or continue) the effort Stefan and I started with CSL (we later suspended the project assuming PortAudio would fulfil the role) to make sound backends transparent.
–
After lunch, Quim Gil presented present and future of the Maemo platform. The points I personally found most notable are:
* libhildon2 is going to become an upstream community project, using Gnome infrastructure like bugzilla, with Nokia providing the core developers.
* Future platform updates (applications and OS) should be possible via APT, so flashing becomes a secondary upgrade method.
* Nokia is currently collecting feature requests for the Maemo platform. They’ll be integrated into Nokias platform plans where possible, so if you have any input to provide, state it here: Maemo Roadmap Page.
* The Maemo versioning scheme now uses alphabetical letters to indicate versioning progress. The current/upcoming versions are:
– [B]ora: current platform (3.x);
– [C]hinook: next platform (4.x) based on Gtk+-2.10, comes with SDKs before launch;
– [D]iabolo: intended to keep API/ABI from here on, unless upstream also breaks;
– [E]lephanta: SBox2 might be available at this time.
* Nokia tries to open up as much of the Maemo platform as possible and they will try to reduce dependencies between opened software and closed platform components in the future. The reason that some programs stay closed anyway are: a) missing legal clearance or licensing for some code portions – opening up code in one division of the company might affect legal claims (IP) on closed components developed and supported in another division); b) code may be subject to hardware vendor NDAs.
* Nokia will embrace attempts such as getting Maemo to run on different hardware in the future, or running non-Maemo software on the N770/N800.
* Nokia intends to introduce abstraction layers for hardware specifics (N770 vs. N800 vs. future devices) where possible.
–
The closing talk for this day was the Gimp presentation by Simon Budig, titled “Pimp My Gimp”. Simon presenting new Gimp features has become somewhat of a LinuxTag tradition over the years, and as usual new Gimp features managed to excite the crowd, even though we also had the usual glitches like a perfectly tested new clone-tool refusing to work on stage. ;-)

Saturday morning started with a vivid presentation on DBus by Marcel Holtmann. Though no stunning new features were presented, he did a good job on introducing the overall architecture and getting the audience hooked up for DBus applications with his presentation and some simple example code.
–
After noon, there was a big podium discussion on preventive data mining of personalized records, currently planned to be realized in upcoming laws by the German government. While the forum was quite interesting and definitely necessary to have at a conference like this, the discussion didn’t present surprisingly new findings for anyone following matters already. The discussion was great however, mostly because of the strong involvement of a rather large audience. It was pointed out that there is a massive lack of public awareness for the incredible data mining hunger of the government organizations and certain big companies, and that this is one of the topics that are rather uneasy to educate the majority of the democratic republic on.
–
Later during the day, Jono Bacon gave his obligatory Ubuntu talk about how Ubuntu cares about user experience and about growing the community. Personally, I still feel that more involvement from Canonical in genuine upstream development such as e.g. the Gtk+ project would be better in the long run for both Canonical and the upstream eco systems.
–
Finally, there was the Open Source Press talk which started out on how CopyLeft used to be the natural state for information exchange since the beginning of mankind, until publishers came into existence in the 16th century and invented CopyRight restrictions to preserve their investments in terms of hardware and human resources. It then was suggested that in a completely networked future computer age, we’ll be back to a pure CopyLeft situation. The presenter didn’t really seem to apply his findings though, when in the second half of the session he assumed that all mass-digestible texts must be edited by publishers and thus unconditionally require copyright laws. He also didn’t want to acknowledge that books existed which are sold and published online or that large amounts of interesting text (>= 500 pages) could possibly be written by non-publishers. While this presentation showed that publishers do recognize and ponder about open content these days, it also made clear that they still have a lot to learn.

As a closing note, I’d like to say a big Thank You to the LinuxTag Orga-Team. All throughout the four days there was an exceptionally good program in five presentation rooms, with up to four additional forum presentations distributed across the booth areas. From our perspective overall event organization went pretty well, this also resonated in German media.

In other news, Stefan Westerfeld summed up our recent development activities in the BEAST News, which may be suitable to sustain everyone eagerly awaiting the upcoming 0.7.0 release ;-)