Eric Raymond has proposed in his essay “The Cathedral and the Bazaar” that given enough eyeballs, all bugs are shallow, using Linux as a particular example. The idea may be true in the abstract, but in practice even if a project has many users it won’t necessarily have enough eyeballs, and most users of the program would just never be inspired to take printouts of the code to bed: sometimes this is because most users of the program aren’t programmers, other times, because the code is badly-commented and obscure, and still other times because maintenance, frankly, often doesn’t seem immediately as much fun as new development. (Not that long ago, someone sent PostSecret the back of a packet of Viagra where they’d scribbled: “These are for my wife’s benefit. When I’m with my new love interest, I don’t need them.”)
But does this mean that we should just throw out reliable code every five years? By no means! That would just mean we had to go over and over through teething troubles and never reach maturity. What we need is a way to make this code maintainable, so that it may asymptotically approach perfection, firstly by maintainable coding practices and secondly by having external support systems. (Knuth has the asymptotic perfection approach to development of TEΧ, of course; interestingly he also recently said that the idea of unit testing didn’t appeal to him because he rarely needed feedback on what would work and what wouldn’t; James Cape pointed out that this runs rather counter to the idea of code maintenance.) Elijah used the analogy of being dropped in an unfamiliar town with no street signs, but in the end it should be possible to drop people in the town and expect them to find their way, given some help.
The kernel does have this kind of structure, of course, and that’s part of why it can be used as an example of the “given enough eyeballs” dictum in the first place. The challenge for the rest of us is to find ways to help paint the street signs, both through keeping the code maintainable and through external structures.
This is all written from Thomas’s private opinion, and not the opinion of Metacity or GNOME or anyone else, really. But this is here to say that a year ago Thomas, in fixing a complicated bug, accidentally removed Metacity’s ability to stack up several small windows in a cascade. On Friday, in GNOME bug 529925, Erwann Chenede found the two missing lines and put them back in. A release is imminent. I am heartened that Erwann read the code, arrived out of the blue, and found the bug. And I would like Metacity to have the sort of code where people take the printouts to bed to read.
(Ah, so good to see the script picked a photo of the Fighting Cocks for this entry where I’ve had many happy conversations over many pints.)
Much busy activity, especially with making sure our bug tracker knows about everything Launchpad knows about Metacity; in particular,
- GNOME bug 530056 – someone says Metacity becomes a zombie process when you start evince. Anyone else seen this? It’s never happened to me.
Checkins on trunk
- ChangeLog, src/core/window.c by tthurman
- ChangeLog, src/ui/preview-widget.c by tthurman
- ChangeLog, src/Makefile.am, src/metacity.desktop.in by tthurman
- ChangeLog, src/core/prefs.c by tthurman
- ChangeLog, src/core/session.c by jensg
- ChangeLog, src/core/compositor.c by iain
- ChangeLog, src/Makefile.am by lucasr
- ChangeLog, src/core/effects.c by tthurman
- ChangeLog, configure.in by tthurman
- ChangeLog by tthurman
- ChangeLog, configure.in by tthurman
- ChangeLog, src/core/compositor.c by tthurman
- ChangeLog, src/core/place.c by tthurman
Hmm, kind of quiet.
- On branches/gnome-2-22: et by plaes, he by yairhr, nn by eskildh, tr by bcicek
- On trunk: es by jorgegonz, he by yairhr, nn by eskildh, sl by mateju, tr by bcicek
Photo: Ye Olde Fighting Cocks, St Albans. Photo by Gary Houston, public domain.