Building Communities, Tracking Bugs and a Terrible Headache

July 7, 2004 10:40 am General

It’s been a pretty hectic week so far. Having only a short time back in Dublin before heading back to New Zealand, I’ve been trying to catch up with as many people as possible which has proved to be quite stressful. Despite that, it’s been good to be home for a while and to hang on in the office for the week. The office, which is usually deathly quiet, has been full of travellers this week – Erwann, Hema, Danese and myself. There is a bit of a buzz around the place.

Danese gave a good talk about Sun Blogging yesterday. It’s amazing to see the progress being made on this front from Sun. At a very rough count we have something like 500 feeds available on PlanetSun and it’s been hugely rewarding reading blogs from right across Sun – what an amazingly diverse and interesting bunch of people that I barely knew existed. Danese mentioned Java.net a couple of times during the talk, and it prompted me to gripe to her about why I think Java.net isn’t a very good model for what we’re trying to achieve. Unsurprisingly, she replied with ‘Blog it’.

Java.net is essentially a Sourceforge model, and while I admire the job its done, it hasn’t been very good at creating consolidated communities. From my outsider viewpoint, Java.net has fostered a whole host of projects, both small and large, but with the developers working in isolation. Each project has their own separate CVS, their own separate bugtracker, their own separate mailing list. It feels like a stretch to call it a proper community. By contrast, the GNOME community is different. We share a single CVS which is host to some 600+ projects. We have a 100+ mailing lists, some of which we share for common interests; desktop-devel-list and gnome-multimedia being good examples. We also have a single bug tracker. But best of all, GNOME is about the people and teamwork. We have accessibility, usability, documentation, localization and QA teams, all working towards a common goal. When you import project into cvs.gnome.org, you can almost guarantee your project will be translated into 50+ languages. People will download your code, log bugs and start to improve the usability or accessibility of your application. It’s a real community, and people seem to forget how powerful open source can be. Java.net doesn’t have this, and I believe we need to move towards that goal. In Sun we seem to be very focused on a Java desktop development strategy, yet we do seem to be struggling on how to create a community for the millions of Java developers out there. It seems there are lessons to be learnt from smaller, yet successful projects like GNOME and KDE.

Meanwhile, the GNOME team sat down yesterday and talked about our bug tracking proposal. In Sun we have a bug tracking tool called ‘Bugtraq’, which feels like an archaic beast. Bugtraq has a mail interface, a motif based application and a web based interface. All of which are equally awful. A while ago I wrote up a proposal to try and address some of the problems we’ve been facing –

  • All of the interfaces to Bugtraq are painful to use, and as the database [shared by all product teams within Sun] gets larger, accessing it gets slower.
  • The database is swamped with untriaged bugs, that may never be looked at ever again.
  • We mostly ignore bugs with a lower priority, simply because we’ll never have the resources to fix them. This has the side effect of wasting time logging a lower priority bug when you know it will never be fixed.

We had a bunch of really interesting discussion – wondering how we can create a more effective process, while still maintaining good QA metrics and an understanding of how stable our product is. At the end of the discussion we came up with some good actions –

  • Developer and QA teams spend a week at the end of our next product cycle triaging *all* bugs, and where there continues to be a bug in the community product, we make sure there is a bug for it on bugzilla.gnome.org. Further, if the bug is a lower priority [non-branding/patch based bug] we close out the bug locally. We do this by setting up VNC so that we can continously verify bugs against a community HEAD build.
  • Better still, QA only log high priority bugs locally [P1 and P2], and log everything else in bugzilla.gnome.org, where appropriate. Developer teams pick up bugs from bugzilla.gnome.org and fix them.

So there’s still a bunch of issues to work out but it feels like a good change of direction into how we contribute to the community, and hopefully it’ll create a potentially more stable product for all involved.

Met up with Hema last night and took her around a few pubs in Dublin – the Temple Bar, the Porter House, the Long Haul and the Stag’s Head. Had a few pints of Guinness and suffered with a terribly bad headache this morning. Didn’t feel exceptionally drunk last night when I headed home – I guess I’ve been away from Ireland too long.

Comments are closed.