Language Selection

English French German Italian Portuguese Spanish

Ubuntu Developer Summit, Mountain View

Filed under
Ubuntu

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:

Full Story.

Ubuntu Developer Summit report: Desktop plans, PowerPC's future,

In this final report from the Ubuntu Developer Summit (UDS), held last week at Google's offices in Mountain View, Calif., we'll look at plans for the Ubuntu and Kubuntu desktops, the future of PowerPC, and how Ubuntu is working with local community teams.

Full Story.

----
You talk the talk, but do you waddle the waddle?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Leftovers: Gaming

Leftovers: Software

today's howtos

ACPI, kernels and contracts with firmware

This ends up being a pain in the neck in the x86 world, but it could be much worse. Way back in 2008 I wrote something about why the Linux kernel reports itself to firmware as "Windows" but refuses to identify itself as Linux. The short version is that "Linux" doesn't actually identify the behaviour of the kernel in a meaningful way. "Linux" doesn't tell you whether the kernel can deal with buffers being passed when the spec says it should be a package. "Linux" doesn't tell you whether the OS knows how to deal with an HPET. "Linux" doesn't tell you whether the OS can reinitialise graphics hardware. Read more