GNOME Boston Summit 2014

The Boston Summit is a 3-day hackfest for GNOME developers and contributors, that we traditionally hold over the Columbus day weekend.

In recent years, we’ve met in Montreal,  but for 2014,  we are back in Boston, at the MIT.

Early Turning


When:    Saturday, October 11 — Monday, October 13
Where:  MIT building E51, Cambridge, MA


There’s plenty of topics we can discuss. Here are some I would be interested in working on:

  • Application development (bundling, SDKs, sandboxing, kdbus, …)
  • Wayland (porting leftovers, possibilities for the future, …)
  • Privacy

If you are interested, please let us know you’re coming.

Hope to see many old and new faces there !

GNOME 3.14 impressions

As part of the release preparation, I’ve done some smoketesting of GNOME 3.14 – looking good! As I usually do, I’ve taken some screenshots while testing things, to share some impressions. Screenshot from 2014-09-24 07:50:18-smallScreenshot from 2014-09-24 09:25:44-smallScreenshot from 2014-09-24 07:30:42-smallNow back to final release preparations.

What the GNOME release team is doing


At the release team BoF at this years Guadec, I said I would write a blog post about the whats and hows and ifs of release team work. I’m a little late with this, but here it is: a glimpse into the life of a GNOME release team member.

We are in the end phase of the development cycle, when the release team work is really kicking into high gear.

Blocker bugs

Since the .90 release, we’ve been tracking blocker bugs.  The way this works is that we are setting the GNOME Target field to the next release. During the cause of the development cycle, we’ve had 50 bugs that were marked with

GNOME Target=3.14

at some point . Today, we’re down to a single one, which will hopefully be gone before the weekend is over.

In order to draw our developers attention to these bugs, we’re sending out regular reports to desktop-devel-list (see them here, here and here). Andre has taken over this task this cycle.

We don’t have formal criteria for what bugs to mark as blockers, we are mostly going by the instinct and experience of bug zapping veterans like Andre Klapper. My own criteria for setting this flag mostly come down to these questions:

Is it a crash in a core component ?
Is it very visible or annoying ?
Will it affect many users ?

For finding bugs that should be blockers, I am regularly scanning all incoming bugs in bugzilla. On an average day this query finds between 100 and 200 bugs – with some practice, one can get through that list in 15 minutes.

We also get ‘nominations’ for blockers from maintainers and developers, which is very helpful.

Development Releases

The duty of ‘doing’ releases is distributed among all of the current, active release team members.

Our development schedule has a pretty well-established cadence of development  releases: We do a number of early development snapshots which are roughly a month apart (3.13.1, 3.13.2, 3.13.3 and 3.13.4 this cycle), followed by the beta releases which are 2 weeks apart (3.13.90, 3.13.91, 3.13.92, this cycle).

The end product of each development release is a set of jhbuild modulesets and a forest of symlinks to the tarballs for individual modules that are included in the release.

Most of the mechanics of creating the modulesets by rewriting our regular modulesets (which point at git repositories, not tarballs), and creating those symlinks on the server are handled by scripts that have been passed down through the generations.

The time-consuming aspect of creating a release is that it usually takes several attempts to create candidate modulesets, hunt down missing releases (or doing them ourselves – which is sadly necessary for a number of ‘weakly maintained’ modules), and do a full jhbuild using the final modulesets. As a consequence, while our official release day is always Monday, the release typically happens on Wednesday or Thursday of the same week.


Towards the end of a development cycle, the release team also starts to plan for the next cycle.

This includes creating the schedule, taking a look at annoying bugs that we should tackle in the next cycle, figuring out if there are project-wide goals that we should push, and collecting input on new modules and features that people want to work on for the next release.

Since we are at this point right now, let me end with this request:

Please let us know what features are on your modules roadmap for the next cycle!

A Wayland status update

It has been a while since I last  wrote about the GNOME Wayland port; time for another status update of GNOME 3.14 on Wayland.


So, what have we achieved this cycle ?

  • Keyboard layouts are supported
  • Drag-and-Drop works (with limitations)
  • Touch is supported

The list of applications that work ‘natively’ (ie with the GTK+ Wayland backend) is looking pretty good, too.  The main straggler here is totem, where we are debugging some issues with the use of subsurfaces in clutter-gtk.

We are homing in on ‘day-to-day usable’.  I would love to say the Wayland session is “rock-solid”, but I just spent an hour trying to track track down an ugly memory leak that ended my session rather quickly. So, we are not quite there yet, and more work is needed.

If you are interested in helping us complete the port and take advantage of Wayland going forward, there is an opening in the desktop team at Red Hat for a Wayland developer.

Update: After a bit of collective head-scratching, Jasper fixed the memory leak here.