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.

Sponsors

• Red Hat is sponsoring breakfast for all 3 days

Suggested Sponsors

• 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.