How do you hack on GNOME? How can we do better?

[Owen Taylor <otaylor redhat com>]

As we move to Wayland, some of the ways we used to work on the core parts of GNOME (like gnome-shell 
--replace) no longer work. I think this is a good time to look at how we hack on GNOME, how we can make it 
more standard and obvious for newcomers, and how we can make it easier.

We can classify hacking on "GNOME" (taken very widely) into the following:

 1) Hacking on system components that require hardware access (kernel drivers, NetworkManager)
 2) Hacking on system components that don't inherently require hardware access (kernel filesystems, systemd, 
polkit, gdm)
 3) Hacking on session level components (gnome-session, gnome-shell, gnome-settings-daemon), and the 
libraries they use (gnome-desktop, clutter)
 4) Hacking on libraries (gtk+)
 5) Hacking on applications

Which ones of these do you do? How do you do it? Is 'jhbuild run' sufficient for your needs? Do you log into 
a jhbuild session? as yourself? as a test user? Do you replace system level components? With 'make install'? 
By building packages? Do you use gnome-continuous?

4 and 5 are handled pretty well by jhbuild. I think we can do better in the future for 5 using xdg-app - 
application checkouts could be entirely self-contained, with 'make' automatically downloading the right 
version of the GNOME SDK if not already present.

3 seems like a place where we can make progress - the vague idea I have is:

 - Move our standard install location back to /opt
 - Have utility scripts that set up a test user
 - Have hotkeys that switch directly back and forth between the main session and the test user session and 
respawn the test session

We could theoretically address 2 by having our standard test setup to run in a VM, but a lot of aspects of 
the system don't test well in a VM - touchscreen input, multimonitor, networking UI, sound, etc. And running 
in a VM isn't possible with jhbuild, so we'd have to switch to gnome-continuous for builds, and it's not 
really designed for the same use case as jhbuild - the initial build and cycle times are much bigger.

Addressing 1 systemically would not only require us to switch to gnome-continuous, it requires actually 
rebooting into the gnome-continuous tree - so in essence the user would be working in an ostree based 
operating system. This seems very much out of scope.

Thoughts? I feel that we don't have a good story for someone coming in and wanting to hack on the core parts 
of GNOME right now, but perhaps there are things that I'm not aware of.

- Owen