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.

Tell us you're coming - add your name to the list to let us know that you're planning to participate

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

Red Hat (Boston/Westford) - Website

GNU / Free Software Foundation - Website

Venue

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

Schedule

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:

ostree

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 gnome.org, 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

Hacking day. See https://blogs.gnome.org/mclasen/2015/10/11/boston-gnome-summit-update/ for results

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

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