Improving GNOME
Why are we here?
- GNOME is people and code that orbit GTK+, a driving user
interface, and Free Software
- People have different motivations
What should we do here?
- Need clearly defined mission (Mozilla: "open web")
- Need success metric (#users? #commits? #lines-of-code? #applications? #forks? #features? #...?)
A brief, incomplete history of GNOME
- Don't rely on proprietary Qt toolkit
- GTK+2, GNOME 2, Sun involvement, a11y
- Ubuntu
- https://live.gnome.org/10x10
- https://live.gnome.org/OnlineDesktop/
- http://www.gnome.org/gnome-3/
How about: We've already succeeded
- A lot of people use our software, for work and play.
- But we regress too often =(
- Thus primary goal is increasing success while avoiding regressions
What's a regression?
Disabling the second monitor makes things work, but with an obvious cost; one might describe it as a new form of the classic time/space tradeoff.
"The Grumpy Editor's GNOME 3 experience", lwn.net. Jonathan Corbet, March 15, 2011.
What's not a regression?
- Intentional design changes that have been carefully thought
through, and where your computer still functions.
- Developers and designers in GNOME have to hold ultimate power;
we can't make the entire Internet happy.
Identifying regressions/feedback cycle
- Almost all testing during the development cycle is entirely
manual, run on individual developer machines.
- Even if we had extensive automated integration tests, it's no
substitute for actual humans attempting to use the code
for real work.
- Almost everyone, except for developers who need to operate
on the code, rely on binaries. Which means in practice,
we rely on "distributions". And distributions here means
packages.
A regression is created by a commit
- Code doesn't break spontaneously; someone had to do it, and with
revision control the change is associated with a person.
- git commit --[time]--> tarball --[time]--> package -> repository --[time]-->
apt-get/zypper/yum -> filesystem -> reboot -> see it
RPM and dpkg make reverting regressions too hard
- Both define "upgrade" to be increase in version number
- Hacking around this (RPM epoch, Debian ~really) are too painful and ugly
- I believe this semantic deeply influcences our culture; kernel
often reverts commits, rare to see discussed in "distributions"
- Oh also, if it breaks, you're screwed.
Improvements in jhbuild since last year
- "sysdeps" extended
- Delete no longer shipped files
- War on -Werror
- git clean -d -f -x
- Default to parallel builds
Why are we still using jhbuild?
- Focused on actual source code in git
- Parallel installs inside existing distribution
- Reasonably fast, allows partial builds
- Package system agnostic
OSTree for developers and testers
- "git for operating system builds"
- Really just a new wrapper for make, tar, and wget, but:
- You can now parallel install bootable things (OSes, distributions) efficiently
Just another step in a long series of related things
High level motivations
- Files being ripped away by package systems while apps/system components are running
- Continuous integration
- Easier for Fedora QA to install LXDE than to help debug/fix GNOME
OSTree properties
- Has essential property, like jhbuild and Live CDs, that it
does not disrupt your existing system.
- Unlike jhbuild, delivers a complete system; you reboot into it.
- Unlike jhbuild, you download binaries from build server
- Unlike Live CD, you have your actual /home, and a writable filesystem.
- Unlike Live CD, easy to modify source code from system "as you see it",
and reboot into your modified system
Bisecting operating system builds
- A git commit causes a regression; OSTree tracks set of git
repositories and revisions that go into each tree
- You can bisect across operating system builds; "my sound broke in the last week"
- I do actually expect users of Free Software to help participate
in bisection.
Not packaging
- Eliminates concept of packages (up to OS)
- Package is partial filesystem with %post shell scripts
run as root attached
- OSTree manages (immutable) named filesystem trees
- A triggers mechanism is centrally-maintained repository
of %post equivalent
- Ostbuild build system focused on source code in git
repositories
Architecture
- Base system: Yocto (uid > 0, tarballs, cross compiler, stable)
- Bootstraps to: "ostbuild" (uid > 0, git, same-arch chroot, continuous integration)
- Contrast with dpkg/rpm: (uid ~= 0, tarballs, same-arch chroot, ~stable)
"GNOME OS"
- A term tossed about; means different things to different people
- My personal motivation: Improve quality in FOSS (for everyone)
- Operating System(n): Your old binaries will run
- Distribution(n): A set of packages
Example: GNOME should not block on KDE
- For GNOME 3.0/Fedora 15, GNOME switched to NetworkManager 0.9,
KDE depended on 0.8
- Could be called a Fedora problem, but then there is a notable
section of Fedora users that only use GNOME, and Fedora is
currently an important mechanism by which GNOME code is
distributed
- Solution: Share source code, as much as possible. Don't
(necessarily) share binaries.
Example: Don't "package" MeeGO
- Rather than wrapping MeeGO in whatever package format:
- ostree-pull http://meego.org/repo meego-1.0-i686-runtime
Example: What should happen when you plug in an Ethernet cable?
- In Fedora, NetworkManager (enabled by default, but not installed
on servers until recently), used to automatically DHCP when an
Ethernet cable was plugged
- Because of server concerns, NetworkManager changed to not do this
- But this breaks client. Have no sane mechanism to distinguish between
client and servers; both just sets of packages.
- Solution: Share source code, as much as possible. Don't
(necessarily) share binaries.
The myth of the "DE"
- There's a bit more to it than picking some letters to prepend to
DE and writing a GTK+ window that sets _NET_WM_STRUT
- Networking
- How GDM allocates virtual terminals impacts everything
- What happens when you click suspend in the UI, then close the lid?
Issues with distributing binaries
Issues with distributing binaries, cont.
- Governance model
- Branding
Regardless, seeing latest GNOME is valuable
- Designers want to see what they're designing
- (A) version of GCC/X.org everything compiles with is defined
- Obvious place to host integration tests
Downsides of OSTree as it exists today
- No guaranteed association between binaries and sources
- Super young code, barely documented, I will change things at will
- My first filesystem/VCS
- /etc really hampers ability to downgrade
More stuff mozilla is doing, and we can too
Questions?