Author: Nathan Willis
In the past, Mozilla has provided only “vanilla” packages of its browser, email, and combined products for Linux users, but in practice most of those users run customized builds supplied by their distribution. The distributions typically patch the vanilla source in order to support differences in lower-level system components like GCC and standard C libraries, but also to add features absent in the official Mozilla code — like better support for some languages using the non-Mozilla text rendering library Pango.
The sheer number of changes made independently by the distros made merging patches upstream difficult, if not impossible, and led to secondary problems like debates over usage of the Mozilla trademark. Furthermore, the current Mozilla policy is to accept only security fixes for stable code branches. Since many distros must continue to support older Firefox releases shipping with their own long-term-support releases, even patches that provide major stability fixes would not propagate upstream.
At the Firefox Summit in November, Mozilla’s Mike Connor met with Christopher Aillon of Red Hat and Novell’s Robert O’Callahan to discuss practical changes that would have a positive impact Linux Mozilla development process. On Monday, Connor posted on his blog about the new tactics.
The primary change centers around forming a new group to oversee Linux-specific development. The group will include volunteers from outside the Mozilla Foundation, representing needs of the Linux distros and other interested parties. They will be responsible for making Linux-specific changes in the code, coordinating patches, and pushing their changes upstream.
That should help the distros by eliminating duplication of effort brought on by each distro maintaining its own patch set. With the distros working together, Aillon explained, “all Linux users will benefit, instead of the user needing to figure out which distribution ships with what patches. The good patches will be accepted and then every Linux user will benefit.”
Coordination should also allow the distros to guarantee that new Firefox releases work with current distros — where unsynchronized release schedules often wreak havoc on compatibility. Last but not least, Aillon predicts benefits through the freedom to innovate. “Right now, there’s no real motivation to do development work for a stable branch since the patch won’t be seen for a long while in official builds. With the new philosophy, there is a quicker return which should help developer mentality and promote innovation.”
For its part, Mozilla will provide links to distro-specific builds on its download page, and provide developers with nightly development builds. Though the initial discussion was specific to Firefox, it may also be extended to cover other Mozilla-based applications like Thunderbird, Seamonkey, and XULRunner.
Aillon wrote about the agreement on his own blog, describing it as a “great step” for Linux users. He hinted that closer coordination with Mozilla could help alleviate some of Debian’s ongoing troubles with the browser over trademark usage, but admitted that a solution is not yet in sight.
Thus far, only Red Hat and Novell have publicly committed to participating in the effort, but several other vendors have expressed interest — including Sun. In the end, Aillon says, it will come down to collaboration. “This is and should be a collaborative effort.”
