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

[Bastien Nocera <hadess hadess net>]

On Mon, 2015-07-20 at 19:11 -0400, Owen Taylor wrote:
> 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)

I wouldn't classify hacking on NetworkManager as being the same as
hacking on kernel drivers. NetworkManager is relatively easy to
compile, but hard to install and test.

Hacking on bluetoothd by comparison is easy: stop the existing daemon,
start the new one directly from its build tree.

Making it easier to start/debug NetworkManager could be something the
NetworkManager folks could work on (even if it means yo-yo'ing in and
out of IRC :)

Hacking on kernel drivers is also pretty easy as long as they can
compile stand-alone, as modules. You could compare the problem of
hacking on kernel drivers to hacking on some parts of GNOME: the
kernel/GNOME component offers a new API, or a bug fix that you need to
work on your driver/application, you end up having to deploy a new full
stack to test that one little change.

>  2) Hacking on system components that don't inherently require 
> hardware access (kernel filesystems, systemd, polkit, gdm)

Every change I made to systemd did require hardware access, FWIW.

>  3) Hacking on session level components (gnome-session, gnome-shell, 
> gnome-settings-daemon), and the libraries they use (gnome-desktop, 
> clutter)

Hacking on gnome-settings-daemon or gnome-control-center is easy
compared to hacking on gnome-shell.

In gnome-settings-daemon, you can disable the plugin through:
gsettings set org.gnome.settings-daemon.plugins.<name> active false
and launch /usr/libexec/gsd-test-<name> or the same binary from your
build tree to test it.

(In the future, we'll likely use systemd units and not use plugins
anymore, making deployment and debugging easier)

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

Even 3) when the component isn't mutter/gnome-shell is straight
forward.

>  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

This wouldn't fix deploying NetworkManager, or make debugging gnome
-shell easier.

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

"Running" is a separate environment is nice to test that it works in a
clean setup, but that's already possible, and has a too big
debug/deploy cycle. When I've double-checked the output of my debug, I
don't want to have to reboot the system to re-test the component after
making the one-line change.

(I have great sympathy and respect for the kernel developers that
bisect core OS problems and reboot their machines dozens of times a
day)

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

Short debug cycle:
- kernel driver that doesn't require framework changes
- gnome-settings-daemon, applications running in the session
- non-essential hardware related integration (bluez, iio-sensor-proxy)

Long debug cycle:
- mutter/gnome-shell
- core kernel bugs
- NetworkManager
- systemd

If somebody finds a way to start a whole GNOME session with the normal
system as a base, overlaid with the software you're hacking on, inside
a container (rather than a VM), I think that the turn around would be
faster for mutter/gnome-shell (including testing extensions),
NetworkManager and systemd.

The systemd developers already use containers to test out systemd
changes, and that's something I'd like to be able to use for system
integration. There are a number of ways to instrument software to make
it think it has the hardware you want (umockdev, dbusmock, uinput...)
if that hardware ends up being unavailable in the container.

Cheers

PS: I'd also like an easy way to integrate with ssh keys when ssh'ing
into a machine to hack on a driver, or debug system integration, but
I'm guessing that's not clearly related ;)