Much of the current configuration decisions about how Mercurial is used for Firefox (gecko) development at Mozilla has roots in days gone by. Usually, they were the best choice at the time to implement the following business priorities:

1. Keep the source safe! (Make it easy to ensure only the desired changes make it into a build.)
2. Remove barriers to quickly addressing chem-spill issues.
3. Scale well.
4. Provide build & release process stability.
5. Have a plan for producing a chem spill release with only 1 data center functional.

Those decisions were made years ago, when hardware wasn't as powerful, and there were few alternatives. Below are the rationale-of-the-day which led to some of these decisions. While hardware and software have improved, the business priorities still need to be met.

Please feel free to add questions below, and we'll try to record the original drivers (as best they are remembered). The goal here is to ensure we don't accidentally undo something, as we make changes to take advantage of improved tooling in infrastructure choices.

Branching Conventions

Why are there so many branches in mozilla-release & mozilla-beta?

The business goal is to minimize the amount of time and confusion to land chem spills patches. We pre create branches at every point one may be needed, so they are available if ever needed.

After a branch stops being eligible for security updates, there is no longer a need to keep those branches. However, the cost to close (merge back to trunk) was believed to be higher than the cost to keep open. (Historically, very few folks worked directly with mozilla-release & mozilla-beta.)

Why is there only one branch per physical repository?

This was driven by the state of the hardware and the business priorities. Having release branches in separate repositories avoided many issues with corruption, locking (it was not uncommon to have commits stripped from mozilla-central as late as 2012). Having each critical release branch isolated reduced the risk of back end operations.

Mercurial (heavy weight) branches were not the issue - these were operational decisions biased towards the corner cases of chem spills and business continuation.

Lore

Callek added (on IRC):

One of the other considerations (at the time) of the release-branches-not-in-hg for e.g. m-c was developer confusion perception at the time we INFREQUENTLY branched off "trunk" and when we did, even in CVS days, there was usually "just one active branch", never two/more so it was perceived that trying to introduce our devs to DVCS branch mechanics, was an added burden that wasn't worth the other costs when many of our devs were just being introduced to DVCS for the first time as it was, (and with that the first time with "whole repo" changesets)