I’ve covered the food and the flight, so now for some actual details about the Ubuntu Developer Summit in Mountain View.
Canonical (or Ubuntu, or even Google, not sure) sponsored travel and accommodation for “upstream” participants, including several people from GNOME and associated projects. Now that’s really working with upstream. We were new to the Ubuntu Summit way of doing things but figured it out quickly. I think we all felt we should be doing more to justify our presence, but hopefully we provided at least some valuable input and advice, and some of us even started implementating specifications. But most of the specifications being considered were lower down in the system, dealing with things such as drivers, devices, X, etc.
The Ubuntu Summits work by discussing specifications and gradually fleshing them out and turning them into definite actions over the week, with Launchpad (trying to) generate a meeting schedule for each day that gets all the relevant people in the right place at the right time to get this done. This Linux.com report about the UDS has a good overview. Matt Zimmerman does a great good-natured job of keeping things on track without being unpleasantly authoritarian. He should have a blog.
These specifications were relevant to us GNOME people:
- Easy Codec Installation: Tim Mueller and Wim Taymans are adding additional details to GStreamer’s error reporting, and Ryan Lortie is implementing an asynchronous (returns immediately, calls a supplied callback later) C API (libgimme-codec) that can take this information and request that an appropriate GStreamer plugin be installed if one exists to support that codec/muxer. I think Canonical’s Ian Jackson is working on the command-line tool that Ryan’s library will use. The idea is that each distro can provide their own implementation of this command-line tool, so that no distro-specific stuff is needed in the applications. We agreed on this really quickly, and most of it was done by the time UDS was finished.
- Composite By Default: Discussion about installing Compiz (or the Beryl fork of Compiz) by default as an option, though it obviously isn’t ready to be used by default. Beryl was favoured in general, I guess because the maintainers were there, and because it was the only one that was currently packaged for Ubuntu. But the maintainers, though nice people, don’t understand the pain that’s involved in being a window manager maintainer, and I think they are more concerned with gimmicks and their settings than with subtle usability or with juggling the often-conflicting needs of various fanatical WM users. People seemed to believe that composite support in Metacity has been abandoned by the Metacity developers, but I haven’t found any evidence of any such decision, and I still hope that can be done, to avoid years of regressions and hate email from bearded types. Packaging it as an option should deal with the feature parity issue for now.
- Face Browser: Mirco Mueller might implement a snazzy 3D face browser for GDM’s login screen, for small business and home users (who don’t have too many users to choose from).
This started out as general discussion about how to make sensible use of 3D effects during login. I don’t think anything more is still specified, but we realized that we could do quite a bit just by handing control of the background to a separate process, much as you can tell xscreensaver to render on the desktop background (X’s root window), with some extra information about the location of the foreground widgets. Of course, this could be abused for irrelevant gimmickery, but I think something subtle and slow could have a nice effect both on the login screen and the desktop background. How can we get Olafur Eliason (not my photos) to design a background theme?
- They had some questions about a couple of items in the Common Customizations spec, about:
- a numlock-on-startup setting. I discovered that the numlock setting is meant to be saved automatically, so no setting should be needed, but that probably only works when session saving is enabled, and it usually isn’t.
- dial-up configuration with the Networking control panel, though I’m not sure whether they have problems with the current “Modem Connection” feature or they were missing support for DSL. The spec has been approved, though it’s still vague about these things.
- Various X specifications: Keith Packard had lots of good news about X.org 7.3, though that won’t be ready for Ubuntu’s next release. All kinds of things should just work, even without a configuration file, and without restarting X, and be configurable generically (without driver-specific APIs) where necessary, such as projectors and multiple screens. He also has high hopes for the new open source (mostly reverse-engineered) Nouveau driver for nVidia cards. I like how Keith can shift from technical-level to user-visible-level easily where appropriate. He’s not your average geek.
- Tab Consistency: Over the last couple of years, several GNOME applications (gedit, gnome-terminal, epiphany, gaim, firefox) have implemented their own closable/reorderable tabs. mostly for document-based applications, but they are inconsistent in how they place the tab close button, how they do drag-and-drop reordering, scrolling of excess tabs, which tab is selected when one is closed, where new tabs are added, etc. Gaim actually has options for most of this, really. Luckily, Firefox 2.0 solves the major problem – it previously had one tab close button while every other application had one on each tab, and GTK+ 2.10 has API that applications could now use to do consistent reordering. GTK+ still needs API for the tab close button. However, the spec was being pushed in the direction of changing all applications (and/or GTK+) to be consistent with the old Firefox way (one close button on the right), which would be a silly amount of work just to be inconsistent with every other distro.
The meetings about the Ubuntu release process were interesting, after my experience on the GNOME release team. It’s mostly similar, though they have a much wider set of things to worry about. I do think they suffer from the tendency that prevailed sometimes in the GNOME release team of looking on the bright side and persuading ourselves that everything would be OK. In particular, I think a mere one week gap between a release candidate (when far more people actually start testing) and a final release is wildly optimistic and probably unnecessarily painful. Anecdotally, Ubuntu Edgy shows the result for me, with at least 5 very user-visible bugs, while Ubuntu Dapper (with a longer stabilisation phase) was remarkably polished.
But I’m just a first-time spectator to that process, and it’s genuinely difficult to schedule enough time for boring bug-fixing and testing while still keeping developers enthused enough to actually do that work. Occasional long-time-support releases are probably a good way to balance that, though I wish there was a way to get more upstream bugfixes into the LTS releases without forcing use of backports of completely new major (with new features) versions.
Otherwise, I spent the time on the GNOME couch (Mirco’s photo) goofing around with the GNOME people more than I have a chance to at GUADEC, such as Ryan Lortie, Christian Kellner, Raphael “unpronounceable” Slinckx, Lennart “Milkybar Kid / Doctor Zee” Poettering, Danilo Segan, and loveable Ubuntu/Canonical people such as Daniel Holbach, Michael Vogt, and Sebastian Bacher (the Frenchest accent since Daniel Veillard). I agree with Ryan – these are people I’d just hang out with for the fun of it if we lived in the same place. It’s also intellectually simulating to meet the other people who deal with such different parts of the system.
I also found time to do some mindless hacking that I don’t have time for normally, such as continuing the port of libgdamm, pygda, and Glom to libgda 3.0, and writing some documentation.
I’m still feeling the Jet lag. Yesterday I woke up after a full night’s sleep, drank 2 cups of coffee, and fell asleep for 5 more hours.
8 thoughts on “Ubuntu Developer Summit, Mountain View”
I really hope ubuntu will choose compiz rather than beryl, nothing against it but it’s clearly more focused on extreme eye candy (with absolutely unneeded things) than usability. Compiz is first of all a freedesktop project, it’s lead developer is the one who really kicked all this work on OpenGL + X, it’s getting better and better every day and it’s trying to accomplish the right balance between eye candy and usability.
Anyway I’m sure the ubuntu developers are smart enough to make the right choice, it could be just me but beryl doesn’t fit well with ubuntu standards IMHO.
This bearded type will surely complain of Compiz or Beryl becomes the default. As they currently stand, they’re gimmicks rather than window-managers. Especially Beryl.
Tab consistency sounds really smashing tough. It would be nice if y’all could get Firefox in on that, but I’m not holding my breath.
I would also feel better with compiz being used in Feisty Fawn.
Metacity has compositing too. All you need is compiled metacity with –enable-compiste(some distros like PLD does it by default), and enable composite trough gconf
Just two random comments:
* Yes, Beryl is focused on eye candy rather than “usability” (I don’t like that word since it carries implications that anyone who disapproves of gnome’s current featurelessness-creep likes unusable programs). I don’t think that’s necessarily so bad.
* There was a discussion on one of the gnome mailing lists about metacity vs compiz/beryl a few weeks ago. The consensus seemed to be that it’s easier to improve compiz than to add all its compositing features to metacity.
Actually, the metacity folks have mostly abandonned their compositor see this thread: http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00314.html
Does the codec thing mean that Ubuntu wants to make it easy to install non-free binary codecs? (Like they want to violate the spirit if not the letter of the GPL with binary drivers in the kernel?)
Tester, I don’t have a problem with making it easy to install software on Linux. I don’t feel the need to make it unnecessarily difficult for people to deploy proprietary software on Linux, though drivers are really another question entirely.
As I understand it, some codecs are not installed by default because the law in many countries would not allow it, due to software patents. However, the law in some countries does allow it so installation should be possible for those people, and the law in some countries may allow it if the user makes a concious decision to do it himself. I’m not a lawyer, clearly.