Buggle Eyed

October 7, 2005 3:16 am General

After 3 days of bug triaging, I’m still on P4 bugs. I’ve definitely pissed a few people off, but I hope they realize that this work part of being more effective at picking up new bugs that are being logged in the future. The P4 count is down from 900+ to just over 400 now and others in the team have already started on the 1000+ P3 bugs that we have.

If it wasn’t obvious from this exercise, Luis was totally right – Everyone Needs a Bugmaster. We would have been much more effective if we had done regular triaging rather than this once every so often approach.

Actually the whole bug life cycle process has been bugging me a lot, and I’ve been trying to think how we might be able to get a handle on things while we juggle managing 2 bug tracking databases – the community bugzilla, Sun’s bug tracker, and now OpenSolaris interaction. So I came up with a new crazy process of how I’d like us to work in the future. Okay, so it’s amazingly naive, and I’m sure it’ll have people coming at me with an axe, but in reflection, it nicely fits in with our long term goal of maximizing our work during the community unstable development cycle, which is going to benefit us much more in the long run.

  1. During unstable community development, log all bugs in bugzilla.gnome.org
  2. When we branch for a stable release [say for the version of JDS going into Nevada], start logging bugs in Sun’s bugtracker
  3. Do our usual analysis based on the data in Sun’s bugtracker in terms of stability, and our GO/NO GO decisions
  4. Once we have a GO in terms of shipping, then we know that the bugs we have in Sun’s bug tracker are either of 2 following states –
    • Update candidates – those bugs that we really want to get into an update release because we think they’re important enough to fix, and may not have had the time previously
    • Not update candidates – those bugs which we care less about, and don’t have the motivation, cost or resources to get them into an update release
  5. Identify all the update candidate bugs that we want to fix, and then close out all the other bugs that will not go into an update. By closing out, of course I mean making sure that the bug is registered in community bugzilla and closing out the bug logged internally.

So, this is a radically different, and so highly political that it may not be possible to pull it off, but I think it’s the right thing to do. It makes us more effective internally, and encourages us to work outside the walls of Sun as much as possible in the community bug tracker if we want a stable product at the end of it. It could be another hair-brained idea, and I’m full of those, but I’m hoping that it might help simplify our business and benefit everyone.

Comments are closed.