I’m in Barcelona to attend the Ubuntu Developer Summit for Karmic Koala, thanks to the kind sponsorship of Canonical, and I thought I’d use the last bit of energy I have left from the first day to post short summaries of the sessions I attended.
Increasing Apport Coverage
This QA session was about increasing the coverage of the Apport automated bug reporting tool. One obvious way to do this will be to increase the amount of packages with Apport package hooks, so the QA team will lead a drive to do exactly that. The target will be to make sure that packages to which a sampling (likely by a 50% reduction) of the last 1000 bugs filed belong have hooks by the next release. The #1 blocker leading to the current situation where we have few packages with hooks was identified to be the fact that few people know that the feature exists at all or is useful to the extent that it actually is. Assuming that there’s a free time slot, a plenary tutorial will be held about this in an effort to remind attending developers and QA people of this relatively simple yet rather important task.
Design and Usability Clinic
This was a hands-on session where the Canonical Design and User Experience Team offered aid to people who needed design/UX advice for their projects in a “clinic” setting. After about quarter an hour of introductions and roundtable talk, the attendees divided up into several groups discussing usability issues in their respective projects. A nice and apparently improvised byproduct was the permanent “UX Clinic” table that got set up in the lounge, around which similar discussions went on intermittently in the rest of the day.
Specialization Within Bug Control
Having more specialist members on the Ubuntu Bug Control team has been a recurring wish. This session focused on the new mentoring program aimed at getting more specialist (and otherwise) people from the Bug Squad into the Bug Control team. Christophe Sauthier and Emmet Hikory from the MOTU team were present to share their experiences with the mentoring model at length, which was beneficial.
Meet Your Users
This design/UX session revolved around (I choose the term advisedly) the theme of “personas”, that is, hypothetical audience stereotypes whom Ubuntu should be designed for. The premise Ivanka Majic, the session lead, put forward was that basing design decisions on the requirements of the more “peripheral” users in terms of association and attachment to Ubuntu and free software would both cover various specialist bases, and ensure that the more central area which has requirements that are more homogeneous and already better catered for would be covered as well.
Attendees suggested various stereotypes along the lines of “students”, “children”, “administrators” and “media producers” on post-it notes, part of which were later evaluated on scales according to criteria such as age, social status, influence level, cultural background, so on.
My only gripe with this session was paradoxically also the major highlight of it: the talk seemed to stay hung up in the air, with no real conclusion or points to act from (the Gobby server failing and the consequent lack of collective notes certainly didn’t help). Of course this was the start of what we hopefully all expect to be a long conversation; the abrupt interruption of time running out only underlined the hunger I felt, and felt that others also felt, for more in-depth discussion of the audience factor in free software design and usability, and that in itself is promising, given that it’s actually gaining traction in Ubuntu now. Had Troy Sobotka, who has been an outspoken, if unforgiving, proponent of audience-aligned design in free software attended, he might have burst into tears of joy.
Finding Tasks For New Developers
Daniel Holbach this session, which focused on coming up with new means of offering “bitesize” work to new contributors to Ubuntu, mainly in the development area, which would further lower the barriers of entry and attract different sets of would-be contributors.
This post is meant to serve two purposes:
- Introduce myself to the planet
- Present summaries of the sessions I took part in at FOSSCamp 2008, which I’ve attended over the last weekend.
As the standard “Hello Planet” routine, here’s a short introduction of my involvement in Ubuntu: I’m part of the Bug Control team and do lots of bug triage, have been active in the Ubuntu Forums since 2005 (mostly in the development subforums for each release, which I also moderate), recently took on the “Forums feedback coordinator” role for the QA team, have been contributing plenty of the release notes since Hardy Heron Alpha 3, am the documentation lead for Ubuntu Studio, and am a MOTU hopeful (mostly absorbing docs and doing simple packaging fixes so far). The last two have been progressing much slower than others, and right after FOSSCamp and UDS, I’ll be focusing on fixing that.
I’ve been an Ubuntu member for some months, and attending FOSSCamp and UDS has finally pushed me to start a blog and have it aggregated in Planet Ubuntu. It may be inevitable that online coverage of physical summits, which are usually a much more intense and efficient concentration of knowledge exchange and interaction than online correspondence, always leaves something to be desired, but I’ve always felt that attendees of free software summits should provide good reportage and share their experiences with the rest of the community in as rich detail as is practically possible, and be open to questions from the more curious.
FOSSCamp is an “un-conference” in BarCamp fashion, whose agenda is developed on the spot. With the participation of many of distributions (OpenSUSE, Debian, Fedora, Ubuntu), upstream projects (KDE, GNOME, Amarok, OpenJDK, Enlightenment, Swfdec, Glassfish, eBox, Samba, OpenOffice.org, OpenLDAP,Terminator..) and companies (Sun, Novell, Google, Canonical, Red Hat..), this year’s event has provided a good opportunity for collaboration and cross-pollination between many key actors in free software.
Below are short summaries of the sessions I attended.
KDE – GNOME Collaboration
Three sessions were held on this topic, with the attendance of more than thirty KDE and GNOME developers, including some freedesktop.org people. The first session focused on the general notion of “sharing”, in an effort to determine what the concrete assets that the two projects can and should directly share are. Common areas in shared APIs (such as the D-BUS API, XESAM) that are up for improvement were highlighted. Another important part of the session was the discussion of data formats that was basically a continuation of previous fd.o discussions. The resolution was that it was a good idea to have a shared data format (for the desktop, themes, icons, etc.), not invent any new URI schemes and try to agree on as few as possible. The outcome of the discussions on sharing of code would be well summed up by David Zeuthen’s conclusion that “sharing more code just for the sake of having done so” isn’t a good idea, and that the projects should instead focus more on better sharing the D-BUS API. Benjamin Otte’s reaction to the topic of the talk at the very beginning also stayed with me: “Does sharing mean doing the same thing?”
Debian – Ubuntu Collaboration
Lucas Nussbaum, who has been thinking up new ways to enhance inter-distro collaboration in general, and specifically collaboration between Ubuntu and Debian for a long time, led this session, which was dominated by the topic of collaboration on sharing and working on bug reports between the two projects.
Ubuntu Brainstorm and Upstream
This session was full of constructive debate on the relation of the Ubuntu Brainstorm website and Brainstorm project to various upstream projects, which is two-fold: first, in its current installation at brainstorm.ubuntu.com, Brainstorm serves as the Ubuntu project’s “idea tracker”, and since most ideas are directly dependent on upstream development, Brainstorm discussions are inherently tied to the status and intentions of upstreams, and second, various upstream projects have expressed interest in having their own Brainstorms.
Ubuntu QA Portal
Stéphane Graber, Lucas Nussbaum and Henrik Nilsen Omma led this session, which focused on the implementation details of a prospective Ubuntu QA portal, similar to the Debian PTS, which would provide global bug stats on a per package basis (including a per package version of the Ubuntu Developer Weather Report), general bug stats, categorized stats (Apport crash reports, reports with patches attached, reports with Bazaar branches linked) and points of contact for each package (Ubuntu developer responsible, triagers, mailing list, Debian maintainer). An important priority of the site will be making it easier for upstream developers to get an overview of the status of their software in Ubuntu, and selectively subscribe to different subsets of bug mail (crashers, triaged bugs, normal bugs, etc.).
Upstream Bug Collaboration
With the attendance of representatives of various upstreams as well as distribution bug triagers and other QA personnel, this session was reserved to discussions on how bug triage workflows can be improved by better coordination between upstream projects and distributions. Upstream developers from Swfdec, gtkmm, Mozilla, OpenLDAP, KDE and Amarok stated their highly varied preferences regarding the kind and amount of bug mail they’d like to receive from distributions.
Some of the suggestions from the attendees were:
- having (more) bug days with upstream developer attendance (similar to the Amarok hug day)
- having more specialized groups of triagers who follow the development of certain upstreams closely and can better triage their bugs
- using distributed version control to keep track of the state of the upstream code in various places
- including the bug filing preferences of major upstream projects in distribution bug triage documentation
The legendary Daniel Holbach held a two hour packaging jam, where he went over the basics of Ubuntu/Debian packaging with a group of MOTU hopefuls, after which he ended up with a to-do list full of action items based on the feedback from the participants on the packaging recipes.
Stable Release Updates
Led by Murray Cumming, who had previously voiced his concerns about the stable release update policy of Ubuntu which restricted his ability to ship a bug-free version of Glom for a while, this session expanded into a more general discussion of how distributions should adjust their update policies to better accomodate the expectations of a diverse range of upstreams. One conclusion was that distributions had to be more relaxed in their policies regarding stable release updates to software with a low potential of impact in the case of breakage, and could adjust the tightness of their policies per upstream, depending on how responsive they are and how well they can work with the distribution developers. Towards the end, Martin Pitt made a summary of the policy exceptions granted to certain software in Ubuntu so far, and Murray was happy to know that his concerns had been addressed.
Collaboration Between Distributions
In this session, developers from OpenSUSE, Debian, Ubuntu and Fedora reviewed the current state of inter-distro collaboration and came up with various new ideas on how to improve it, some of which were
- a cross-distro package cross-reference list/database
- a single place for upstreams to see the versions and status of their software in all major distributions
- continued distribution collaboration meetings, possibly with support from the Linux Foundation
Ubuntu Software Website
Michael Vogt held this session on a possible “software.ubuntu.com” (that’s not necessarily the address, but sums up the idea) website, an online variant of gnome-app-install, that would provide a convenient way for end users to install applications from the official repositories via apturl, presenting screenshots, concise and non-technical descriptions and documentation. It was agreed that the site should present an end user oriented subset of the packages in the archive only (no libraries, etc.), and that care should be taken in mixing the “download from website, double click, next, next, finish” paradigm and “search in a local application that grabs packages from centralized repositories” paradigm, and the user should be well educated on what exactly is going on. An old prototype posted to the Ubuntu Forums in 2005 was also reviewed as an example.
That’s pretty much it. If you haven’t attended FOSSCamp and there’s something you’re wondering, or if you’re an attendee and I’ve misreported something about you or your project, let me know in the comments. It can also be a good idea to list what didn’t exactly work as intended in this year’s event and discuss what can be improved in future events; if any participants are interested, we can perhaps arrange a forum for such a discussion.