In August Productions

Launchpad is a wonderful and powerful tool. With that comes a variety of different ways different features can be used in the context of a project. I thought I'd take a moment to write down how we're using bugs and when we use what statuses. There are two goals here:

• We could do better at this ourselves
• Maybe it's useful for someone else who is getting themselves ramped up on Launchpad.

Step one is reporting a bug. This may go without saying, but at some point someone will file a bug, and we'll need to notice that - so we have launchpad bugs set up to mail everyone in our main drizzle team any time a bug is reported. This ensures that they don't go unnoticed.

When a bug is first reported, it starts life in the status "New" and with an importance of "undecided".

The next state is "Confirmed". In a perfect world, this bug achieves this state when someone other than the bug reporter has independently been able to reproduce the reported problem.

"Triaged" comes when the bug has been assigned an importance, someone to work on it, and an initial target for completion. Often Confirmed will get skipped and it'll go straight to Triaged, actually, because often times the person confirming the bug is also assigning to to someone.

A quick digression on targetting... in Drizzle we create a new Series for each planned release - such as cherry, dexter or elliot, and then we create bi-weekly milestones to track our bi-weekly tarball drops. So a bug can be targeted to a series and a milestone. The milestone may (and often does) move, depending on whether or not we were successful in getting it done. Once it's been targeting to a series though, it will forever have some status for that series. So if a bug starts in cherry and it doesn't get fixed and we release cherry and move on to focusing on dexter, we don't remove the bug from cherry - the bug is still there in the cherry release after all. If we were doing maintenance releases on things (which we're planning to do once dexter is out the door) we might leave the bug open in its cherry status until a fix has been made in trunk and backported to cherry. Or, since we're not currently doing that for cherry, we'll just set the bug to "Won't Fix" for cherry and track its status in dexter. 

This leads us to the next two statuses... Invalid and Won't Fix. It's possible that the bug, as reported, cannot be reproduced. In that case, instead of setting the status to "Confirmed" - we'll set it to Invalid. Similarly, if the bug can be reproduced, but we think the behavior is valid, we'll set it to "Won't Fix". We have not started to use the new "Opinion" status yet.

"In progress" means that the developer assigned to the bug has actually started work on the bug. This one gets missed the most, because it requires website interaction from the developer, which is usually not what they're thinking about doing when they're coding.

"Fix Committed" and "Fix Released" are the ones most up to interpretation in general. In Drizzle, we use them to mean "A Fix has been committed to some branch and pushed to Launchpad" and "The fix has been pushed to trunk" respectively. I would personally love a third status "Fix Merged" which I could set it to when we set "Fix Released" now, and then use Fix Released for when the fix has hit a tarball... but I'll live.

To sum up:

• New - reported and not looked at
• Confirmed - someone has reproduced it
• Invalid - could not be reproduced
• Triaged - has been assigned an importance and a release target
• Won't Fix - reproducible but no intention to change the behavior
• In Progress - a developer is actively working on it
• Fix Committed - a developer has pushed a branch containing a fix for this bug to Launchpad
• Fix Released - the branch containing this fix has been merged into trunk

While sitting around with Stewart, Eric, Max and Beer at the MySQL Conference and Expo, Stewart thought it would be funny if someone would do a graph showing the trend of Google searches comparing NoSQL and Your Mom. Always wanting to make Stewart laugh, I ran over to Google Trends to see if it could make a graph.

NoSQL vs. Your Mom

Given all the hype these days, you might think that Your Mom would stand no chance against the Juggernaut of NoSQL. But I was quite surprised to see that Your Mom really stuck it to NoSQL. Giving NoSQL some credit, it is making some progress.

Surely then it's a bogus test. I'm graphing tech jargon against a phrase in the common vernacular. It must be the case, given that MySQL is being replaced with NoSQL everywhere, surely adding MySQL in to the trends mix would just make me a sad little Fail Whale.

NoSQL vs. Your Mom vs. MySQL

Oops. MySQL still seems to be considerably more popular than Your Mom. Perhaps suppositions made while sitting in the Hyatt aren't always correct.

I've been making some improvements to our use of Hudson recently that have been really helpful.

The first was starting to use a set of parameterized builds. These use the Parameterized Trigger plugin, which allows you to pass parameters to triggered additional jobs when a job finishes. So using these we make a job which checks out the latest source (which should just about always succeed) and then fire off a whole host of jobs running on all of our build hosts. It has a single "build now" submit form which takes a bzr branch location as the branch to build. With this all of our developers can check their tree against the build farm before submitting the branch for merge.

That's great, but as we got more and more build hosts, we had to set up a job on each of them - and then having 4 machines which were all amd64 running Ubuntu 9.10 didn't help - it ran on all of them.

Enter PlatformLabeler

Robert Collins wrote a plugin for Hudson which checks a build slave for OS details when it connects (architecture, OS and OS Release) and adds Labels to the slave based on the values it finds. With that - instead of targetting a job to say, hades.inaugust.com, I can target that job to x64_64-Mac-10.4.1. I can easily see both platform coverage, and I can take advantage of having multiple machines with the same config, since it'll run the job on only one of them sharing that label. 

The next problem with that setup is that there is not a tight binding between the parent and child jobs. You can see that the parent job triggered the child, but you can't really get a single snapshot of "how did this job work everywhere?" If you're doing this pre-merge request, it might be nice to get a URL you can refer to saying "hey! check it out, it worked"

Enter Matrix Builds.

Matrix Builds are a single job. They allow you to define how you run the job, and then you can select which hosts to run it on. You can also set up arbitrary sets of flags and hudson will build a grid. So in our case, I set up a job (shortened for brevity)

 ./config/autorun.sh

 ./configure

 make distcheck

Then I told hudson to build it both with and without the --with-debug flag to configure, and on a set of our build hosts. Now when I kick it off, I get a page with an overview of how that particular build went. Also, having one build description means I don't accidentally do something different on one host.

Matrix Builds also have a nice feature for a sentinel or canary build, which let you build first on a host where you're pretty darned sure it's going to build, and then build everywhere else. In our case, if it doesn't build on 64-bit Ubuntu 9.10, it's very unlikely to build anywhere, so we don't bother trying. 

I still use the Parameterized Trigger from the Matrix build to kick of jobs for things like Valgrind and Sysbench when the build completes cleanly. Those jobs themselves can be launched independently (if you only wanted to check how valgrind is treating your new branch)

Moving forward, I would love to migrate our main set of build branches to Matrix builds, but Matrix currently lacks support for launching an individual sub-build. If it doesn't show up soon, perhaps I'll add it... ah the joy of open source! 

See the Hudson link at http://hudson.drizzle.org/view/Drizzle-param/job/drizzle-param/ for more details and examples.

 EAVB_QMDBEOGUYE

Any good piece of infrastructure software should be able to pop up little windows on your desktop. :)

Yesterday at LCA in Stewart's Hacking Drizzle talk, it occurred to me that error messages should pop up little windows on my desktop. So I wrote an error message plugin which uses libnotifymm to send Gnome pop-up window messages.

I don't always get to post screenshots, so here you go: