Life is so good, it gets better every day

Better Tools

Mikael, there’s absolutely nothing stopping you from installing OpenSolaris/Solaris and using DTrace though – I and others would encourage it. Those tools are still available, and it might even run on your choice of hardware. Don’t forget the CDDL is just an attempt to stop the proliferation of software licenses – it’s a filed based, templated license, with the Mozilla Public License under the hood, and it was chosen for pretty good reasons, I believe.

Obviously there’s also nothing to stop you from taking those ideas and reimplementing them somewhere else – Jonathan even said so publically at OSCON, ‘knock yourself out’. The BSD guys are already on that path, with some Sun engineers helping them along the way. I’m sure the SystemTap guys will learn from DTrace as well, with time.

DTrace on OSX then, Mikael? *cough*

Solaris WiFi

I’ve been playing a lot with setting up my new Solaris laptop. It’s so nice to have a small, light laptop that doesn’t hum like a Boeing 747. One of the things I struggled with was getting wireless working with the new wireless tools. Seemingly the driver for the Intel Pro Wireless 2200BG [not yet released on opensolaris.org] requires you to publicize the ESSID from the access point. Not only that, for some reason it didn’t like the access point handing out a different address space to my router, so configuring that as a pass through made things work like a charm.

Update: Joshua Stein points me to a fix in the BSD driver for the ESSID fix. Seems it was fixed in 1.49 – hopefully that fix can propagate into our sources. Thanks Joshua!

Also got pointed at some nice GUI network scripts from Mike Ramchand and Darren Moffat to help me on my way. And for the first time *ever*, I’m using zenity for something other than looking at my easter egg.

Next up, GNOME 2.12 and an IRC client.

Kung Fu Hustle

Met up with Phil last night to go see Kung Fu Hustle in the late showing. Wow, this is just an incredible movie. There’s not too many movies you go to these days where you immediately walk out of the cinema thinking ‘I want to see that again, tomorrow’. Not your average martial arts film – but funny, stylish and for once, a good story and character development. I totally recommend this for anyone who hasn’t yet seen it.

Buggle Eyed

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.

New Laptop!

My new laptop arrived yesteday – a nice new Toshiba Portege M300, as well as a nice long life 12 hour battery. Spent some time downloading the ISOs for Solaris Express Build 22 and installing them. Everything seems to have gone well and quite looking forward to the challenges of running a 100% Solaris laptop as my main development box.

However, right now I’ve powered down the new laptop, closed the lid because I want it to be a nice treat after I finish this bug triage. I’ve gone through about 600 bugs in the last 2 days and managed to close a whole heap of really old bugs. Only another 400+ P4 bugs to go – fortunately I think I’ve started a trend and others are beginning to help now. If I seem responsive and unmotivated, you’ll know the reason. Triaging is *hard*.

Dear Federico

Dear Federico,
Use DTrace. You’re killin’ us here…Seriously.
Love Gman.
P.S. Good work though, except with your choice of tools 😉

I Want To Be A Luis

I always admired Luis, ever since Ximian signed a contract to Sun for supporting us with our GNOME 2.0 work. I don’t know how he managed it, but looking through 1000’s of bugs day after day was a herculean task. Of course behind anything like that is a good woman, and I suspect having Krissa over in Africa might have helped his concentration.

That being said, over the last 2 days I’ve been trying to triage the 1000’s of bugs in Sun’s bug tracker. Historically as a team, we’ve basically avoiding regular triaging of the database and focused on P1’s and P2’s – we even got temporary waivers to avoid looking at P3’s, as we couldn’t cope with anything more with our current resources. This kinda means that anything logged as lower than a P3 gets ignored, occupies space in the database, and rots away untouched. It’s a sad reflection of not really being able to coordinate our efforts better between a community bug tracker, and our own internal one. I think we’ve done a pretty ok job about getting a stable product at the end of any given cycle, but our process feels a little broken when you have people logging nearly every bug as a higher priority only because they know logging it as anything else won’t get it fixed, let alone looked at.

I’m going to spend the entire week going through the database. I’m pretty sure that I’m going to piss off a *lot* of Sun people with what I’m doing. I’m going to generate 1000’s of emails. And sometimes, I’m going to get things wrong. I’m using my best judgement in 5+ years of GNOME development, but everyone makes mistakes….