I sat down to write a screed on the wonky Aviary branch happening at mozilla.org, but I’m a little under the weather and thoughts aren’t flowing as clearly as I’d like. I might come back to this later, but thought I’d post what I have just so it’s out there.

In Real Life I do quality assurance, including being the de facto source control guru. As part of this I help to manage change in our source tree; in large part I try to stick to the best practices put forth by Laura Wingerd and Christopher Seiwald at Perforce Software, because for the most part they’re simply formalizing common sense.

The Aviary branch of the Mozilla browser and mail programs was created to be used for stable branch builds of these apps from now until the 1.0 releases of these apps. The Mozillazine FAQ says that the trunk is for Continued Mozilla backend development. Unfortunately, the brunk policy (if there is one) is that development can take place willy-nilly without being propagated back to the main codebase. Logic, and the rationale behind the branch in the first place, would suggest that disruptive changes–new features, modifications affecting interoperability, and other substantial alterations–be created off to the side and then merged into the so-called stable branch when they are–wait for it–stable. Stable changes in the branch should be merged back to the trunk sooner rather than later [because] postponed and batched change propagations can result in stunningly complex file merges.