Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Thursday 4 October 2007


David Baron and I tried a new approach to layout triage, using a Google Docs spreadsheet to record our decisions collaboratively. I added some automation steps so the overall workflow goes like this:

  • Use the Bugzilla query to locate bugs which have been requested as 1.9 blockers.
  • Download the query results in CSV format.
  • Use a trivial Perl script to trim off columns I don't want and add a new column which is the Bugzilla URI for each bug.
  • Import the CSV into a new Google Docs spreadsheet.
  • Add columns in which David and I can each write our evaluations.
  • Invite David and Damon as collaborators.
  • David and I read the bugs (with the help of the URIs, which Google Docs makes clickable) and add evaluations to the spreadsheet (the Real Work).
  • Discuss any differing evaluations until we converge on a decision. Mark decisions by bolding the evaluation we settle on.
  • Export the spreadsheet to HTML and save it locally.
  • Run another Perl script to identify the bolded decision for each bug and generate a Coscripter script to update all the Bugzilla bugs!
  • Run the Coscripter script.
  • Go to lunch.
  • Return from lunch, discover that my laptop went to sleep while running the script, and restart it from the last not-updated bug.

I'm not sure whether this saved much time, in the end, compared to just exchanging comments via email and marking bugs manually, but it was a lot more fun! (And marking bugs manually is very very tedious, at least when you're on a different continent to Bugzilla.)

Also, during this exercise I played around with Google Docs a little bit and discovered that their charting tools use SVG! Excellent!

Here's the Coscripter-generation-script, by the way:

#!/usr/bin/perl -w
sub resolve {
my ($bug, $resolution) = @_;
if ($resolution eq "blocking") {
print "* go to \"$bug\"
* select \"+\" from the \"blocking1.9\"'s \"blocking1.9\" listbox
* click the \"Commit\" button\n";
} elsif ($resolution eq "wanted") {
print "* go to \"$bug\"
* select \"-\" from the \"blocking1.9\"'s \"blocking1.9\" listbox
* enter \"[wanted-1.9]\" into the \"W\" textbox
* click the \"Commit\" button\n";
} elsif ($resolution eq "minus") {
print "* go to \"$bug\"
* select \"-\" from the \"blocking1.9\"'s \"blocking1.9\" listbox
* click the \"Commit\" button\n";
my $bug;
while (<>) {
foreach my $cell (split(/<td/)) {
if ($cell =~ m!(http://.*)!) {
$bug = $1;
if ($cell =~ m!class='g s4'>(\w+)!) {
&resolve($bug, $1);


David Baron
The thing that annoyed me most during this exercise was actually the basic spreadsheet UI in google docs. If I had a cell selected already, I wanted a single click inside that cell to give me a caret inside the text already in the cell. However, that wouldn't give me a caret to edit the text already there, and if I typed, I'd replace the text.
Shaver pointed out to me that if I double-clicked in the cell (whether or not I'd already selected it), I'd get what I wanted. But I couldn't get that into muscle memory even after a bunch of tries.
Db, I have the same problem with the spreadsheets and I just learned to hit enter to allow me to edit the text. It needs to be more mouse friendly and let me edit more stuff with charts like colors and scales and not select like a1:d20 but be able to select multiple cells like a5:d5;a4:d30 and then pick which column or row is the label. Its still beta though...
OK, so what would Bugzilla need in order to make this process work more smoothly in the system than out of it?
Let's start with one it does do - you can choose the columns you want on your query using URL parameters and/or setting a cookie, although I'm not completely certain there are docs for it. But you can't ask for the URL to be one of the columns; that should certainly be an option.
James Napolitano
>OK, so what would Bugzilla need in order to make this process work more smoothly in the system than out of it?
It sounds like it needs the ability to add a column of editable text fields (for the evaluations) to a bug list/saved search. You'd also need a column of checkboxes to select which bugs you'd want to update. The ability to view or just edit the list would have to be restricted to a certain group, like drivers, but I think Bugzilla can already do that. There's no need to add the bug URIs because you already have links to the bugs right there. (you could force it to display the bug URLs anyway by adding some CSS to the bug links, i.e. a:after {content: attr(href); } )
Since Mozilla uses Bugzilla so extensively but has to resort to using external tools alongside it, maybe the MoFo should provide a grant to Bugzilla or EverythingSolved to add in the features it needs. It could almost pay for itself in saved time.
Robert O'Callahan
Yes, some way to to bulk changes efficiently would be useful. What James suggests about adding editable fields to a query results page would be useful. Another interesting option would be to support uploading of changed bug data in CSV format.
There is a bug on editable buglists - https://bugzilla.mozilla.org/show_bug.cgi?id=246272.