We’re having a string change on a stable branch, and I’d like to give an overview of what I did how to make this less painful. Less is intentionally a relative measure, it’s still really very badly painful.
The biggest part of this change was to actually settle on the intended outcome. How should locales behave that make the change, how should locales behave that don’t. What should happen to users with language packs, and what with the language pack versioning. In this particular case, language packs aren’t loaded yet, so they don’t really matter, but in general, it’s a question worthwhile answering.
Now, how to get those changes? The (IMHO) best way is to get patches from the localizers that apply easily. The previous step should identify a concrete patch to implement by the localizers. That didn’t work out perfectly this time, but we caught the difference in time.
Landing seperate patches in tracking bugs leads to all kinds of messy problems, so I went for one bug per language in CVS, whether built or not, and one central tracking bug.
Bugzilla magic, part 1: How to file 50 bugs without getting totally frustrated? I created an HTML form which takes an initial comment, the summary, a blocked bug, and then, on the press of a button, creates bug-filing links for all locales. I hard-coded the list of locales for now. It substitutes @AB_CD@ in all fields for the current locale, and picks the right component in the Mozilla Localizations product, which works for all languages but Slovak right now. The goodness of us hunting for bugzilla components now. I can then click on each link, or just use keyboard navigation. Just opening the links via window.open() works, but really stress tests bugzilla (and Firefox), so that’s not that good. Anyway, it took me about 50 minutes to file 57 bugs. That includes a bunch of distraction while waiting for bugzilla, I’d wish filing bugs would be a snap. Still, not bad, less than a minute per bug. Released lanuages block the tracking bug, others don’t, which was hand-work for now.
For the non-released languages I made those block the central bug once they had a patch.
Within 24 hours, we had 20 patches, within 48 hours, we had 36 (plus 1 which I still have to find out why it didn’t apply). I had to adjust only two patches myself, all others where either fine from the start, or fixed by the localizer on my comments.
YAY on our localization community.
Now, do you want to apply some 36 patches by hand? I don’t, so
Bugzilla magic, Part 2: Creating a bad big patch. Create a bug query that gets all bugs that block the tracking bug and have an attachment that is a patch (“Attachment is patch”, “is equal to”, “1” is the magic trio) . Then click on the XML button, which creates one XML document of all bugs on that query, including all the information. And attachement IDs :-). Now open Jesse’s jsshell bookmarklet and get the attachement IDs:
res=document.evaluate(‘bugzilla/bug/attachment[@isobsolete=”0″][@ispatch=”1″]/attachid’,
document, null,XPathResult.ANY_TYPE,null);
out=[];nd=res.iterateNext();
while (nd) {out.push(nd.textContent);nd=res.iterateNext();}
out.join(‘ ‘)
Now I moved over to bash:
for att in <insert list of attachement IDs here> ; do wget –no-check-certificate -O- ‘https://bugzilla.mozilla.org/attachment.cgi?id=’$att > $att;done
cat all those patches together, test the patch and fix the chunks that don’t apply, and off you go with 36 fixed locales in 48 hours.
About filing the bugs, wouldn’t it be easy to create a bookmarklet which works on a ‘new bug’ form, prompts you for the locale name and automatically fills in the fields and submits the form? It sounds easy enough :), just 1. click a bookmark to ‘new bug’ and then 2. click the bookmarklet, 3. fill in the country code, and 4. repeat 50 times (for each locale).
~Grauw
Comment by Laurens Holst — March 8, 2007 @ 9:06 pm
Did you know that Bugzilla already has the ability to bookmark the contents of a bug filing form as a template? So you can fill in all the common bits, bookmark the result, then load the bookmark 50 times and fill in the changing bits.
See the “Remember values as a bookmarkable template” button at the bottom of the enter_bug.cgi form.
Gerv
Comment by Gerv — March 9, 2007 @ 5:47 am
Lauren, I’d have to have the list of locales in my head for that. 57 letter codes just don’t fit.
In general, I’m going to be doing this on a somewhat regular basis, I’m afraid, latest for the sign-off and verification bugs for Firefox 3, I’ll need this again. At which point the lack of being able to feed an alias via the URL is going to suck. Is that a DUPE of https://bugzilla.mozilla.org/show_bug.cgi?id=310532?
Gerv, same problem as with Lauren, I’d have to enter 57 cryptic charcodes and make sure that I didn’t forget to replace something here or there.
I could really use a bugshell, I guess.
Comment by Axel Hecht — March 9, 2007 @ 6:21 am
Sounds like it would be easiest to write some sort of perl/python script to file the bugs given a list of parameters. The only tricky part would be making it use your bugzilla login, but a few HTTP libraries support using cookies.txt.
Comment by Ted Mielczarek — March 9, 2007 @ 6:42 am
Ted, the biggest problem I had with my approach was the bugzilla performance. One has to somehow schedule the big filing, I’m not sure how well bugzilla copes with getting hit by 60 parallel bug filing requests all blocking the same bug. Filing a single bug takes several ten seconds.
And js scripting is perfectly fine for me.
I could probably directly post the form, too, but I found having a control view on the filled out form to work nicely. And there are some odd ends, like, Slovak Component doesn’t match like all others, and there are a few bugs that shouldn’t actually block.
Comment by Axel Hecht — March 9, 2007 @ 8:15 am
blog markup sucks, I need this so that I can copy and paste it:
for att in ; do wget –no-check-certificate -O- ‘https://bugzilla.mozilla.org/attachment.cgi?id=’$att > $att;done
Comment by Axel Hecht — March 14, 2007 @ 6:50 am