June 6, 2005

Making the Talkback client build more robust against server failure

Posted at 17:13 in Mozilla and mZ and planet.m.o.

Over the last couple of months we've run into our fair share of issues with the Talkback client not being included in various builds. Whenever the Talkback servers hiccupped, build systems would feel that pain. While keeping the Talkback servers in steady shape is an on-going effort (Jay, our Talkback expert, can attest), the Talkback client going missing from these builds was an ugly side-effect which would bite us at any time -- whether during a nightly release build or a release respin. The result being that we would need to respin the affected builds again, delaying everyone's work further.

Peering into the mysteries of the Talkback server some time ago, we found we could cut the servers out of the loop and generate the necessary parts for the Talkback client without any server interaction at all. The main thing holding us back was that we had no time to implement and test the changes. Last week offered an opportune time to make such a big change to the build process, having just completed our release of Firefox and Thunderbird 1.1a1.

As of noon last Saturday, all release builds including the Talkback client that are built from the trunk, the Mozilla 1.7 branch, and the Aviary 1.0 and 1.0.1 branches no longer require interacting with the Talkback server to build the client. While the client build can break and has broken before for other reasons (eg, API changes in the core Mozilla code), the most common cause of the client breakage in our nightly builds has now been resolved.

I flipped the switch on this but couldn't have done it without Shiva T. and Jay. Thanks to Shiva for his pointers on what to look out for when generating the master.ini templates and Jay for his verification work that the Talkback client still functions as expected after the changes were made.

Comments

3 comments received. Post a comment.

Is there any reason that the master.ini is in the Firefox application folder and not in the Profile folder? (not that I understand what master.ini is about btw.)

Problem is that Talkback-Reports dont show up when deleting application folder and unzipping a newer Nightly in same place while testing the trunk builds.
A previously produced Talkback-Report that was not yet send due to Talkback-Server unresponsiveness will be lost.
- Unless copying the old master.ini to the newer build, but is this valid?

Last Question: Will Talkback be enabled by default in Nightlies AND Hourlies?

Good move to make Talkback more robust :)

Posted by: Stebs at June 6, 2005 6:49 PM

Sorry, forget last question, just saw a comment from you that talkback is only for the release builds because of disk-space concerns.

Posted by: Stebs at June 6, 2005 6:55 PM

Any chances to have a newer talback client able to send reports thru authentifications proxies ? (This would be nice, and would help crashers found in corporate space).

Posted by: Ludovic at June 6, 2005 11:34 PM