Summit 2015

When: Saturday, October 10-Monday, October 12 Where: MIT building E51, Cambridge, MA

GNOME Summit is a three-day hackfest for GNOME developers and contributors.

It is not primarily aimed at users or new contributors, but if you want to jump right into the deep end, it's a fantastic way to meet everyone and get involved. Unlike traditional conferences, the Boston Summit is all about getting developers together and getting things done. While there are some non-hacking sessions, they are geared heavily towards many-to-many, interactive discussion and planning, rather than one-to-many presentations.

Code of Conduct

GNOME Summit is dedicated to a safe and friendly conference experience for everyone. By attending the event you agree to follow our code of conduct.


  • Red Hat is sponsoring breakfast for all 3 days

Suggested Sponsors

  • Red Hat (Boston/Westford) - Website

  • GNU / Free Software Foundation - Website


  • We have a confirmed reservation for MIT, building E51.
  • Time: 9:00a - 6:00p
  • Classroom: E51-315, E51-325 & E51-335

Proposed Topics

  • GNOME Empathy
  • GNOME Notification Area
  • Building GNOME from Scratch
  • What's New in GNOME (various O/S stats)
  • GNOME State of the Bugs (Bugzilla/Speed-Profile)
  • Customizing the Desktop
  • GTK / Glade
  • Builder
  • Xdg-App
  • GNOME Continuous
  • Wayland remoting

  • the right click project (view source and debug anything from anywhere)

Topics Listed at the Opening

  • xdg-app
  • ostree
  • gnome-continuous
  • performance (counters, hacks, etc)
  • xdg-app vs. docker
  • gnome-builder
  • GTK+ feature requests
  • Wayland non-integral scaling
  • low-res mode
  • Wayland remoting
  • Wayland in general
  • API docs roadmap
  • unmaintained modules


We'll start each day with breakfast at 9:30am and sessions at 10am sharp. The rooms are reserved until 6pm each day.

On Monday, Dan Walsh will come by around 1pm to discuss the overlap of xdg-app and container technologies.

Notes from Saturday

Morning session:


  • Colin wants to unify gnome-continuous and xdg-app runtime builds
  • Alex wants a way to represent commits as a single file, for shipping bundles
  • Owen asks whether we need to provide a build or hosting service for xdg-app
    • Colin mentions that this will be similar to copr
    • Possible problems with hosting: legal review needed
  • For production builds you want full builds, developers need incremental builds
  • gnome-builder needs to be able to build bundled components for building an xdg-app
  • gnome-builder will need some kind of project file to now these things (Christian has avoided that so far)

Module definitions

  • jhbuild (modulesets)
  • gnome-continuous (yocto + manifest)
  • xdg-app runtimes (yocto + specs)
  • xdg-app app autobuild ("copr")
  • gnome-builder app dependencies
  • elementary requires a github repo with a cmake file for their app builds
  • Owen has a gnome-continuous-kernel git module
  • Christian brings up the question of application plugins
  • Alex brings up the question of charging for applications
  • Plugins
  • Registry:
    • Donations ?
    • Closed source software ?
    • Automated tests
    • Blacklisting

Conclusions of the morning session

  • xdg-app and gnome-builder will use some recipe file that lists dependencies and the used sdk
  • this recipe can also be used for the 'copr' use case
  • if we're hosting xdg-apps on, we will have to have some light-weight verification of legal and other requirements

Afternoon session:

gnome-builder demo

  • Lots of cool stuff demoed, including performance counters, lots of editor details, keybinding overview
  • The demo included quite a bit of discussion builder plans
    • glade integration
    • gitg integration
    • make output with jump-to-errors
    • xdg-app integration
  • Towards the end of the afternoon, we switched to hacking

Notes from Sunday

Notes from Monday

Wayland remoting

  • We talked about getting frames from the shell into a separate process for using pinos. Wim Taymans has done a proof of concept of this
  • There will be a separate process to implement the remoting protocol(s), very similar to vino
  • vnc is a very attractive protocol to implement first, because there is a wide variety clients, and everybody knows it
  • After vnc, there are many different possibilities. rdp is hard to find the right subset to implement. Streaming with a video codec like h264 is attractive, also because it can possibly be hw accelerated

Nonintegral scaling

  • Need to let clutter render to a hi-res framebuffer, and downscale to individual monitors. GTK+ will still just upscale by an integral factor
  • The infrastructure needed for non-integral scaling is very similar to what is needed to do color correction

Wayland in general

  • It is very much day-to-day usable, with some minor annoyances
  • Proprietary drivers: Nvidia is doing things internally, but we don't know what or when it'll be ready
  • Annoyances:
    • Debugging mutter is hard while running a Wayland session
    • Terminal sizing problems
    • GtkSourceView completion popup placement

    • Window placement (always at 0,0 ?)
    • text-scaling-factor not respected for shell chrome under Wayland
    • no xsettings interface


Organization notes on promotion, breakfasts, and a social event were created based on the experience with this event.

Events/Summit/2015 (last edited 2015-10-12 15:51:46 by MatthiasClasen)