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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
