Building betas from mozilla-beta branches

Philipp Kewisch mozilla at
Tue Dec 15 08:40:31 UTC 2015

On 12/15/15 2:03 AM, R Kent James wrote:
> Any objections or comments?
I don't think this is a good idea. While I understand it is nice to not
depend on Firefox drivers approving m-b patches, I think this will buy
us into more trouble than it is worth. It was ok on ESR because the
volume of changes is not very high, but commits are more frequent on m-b.

What would the treeherder builds be running on? If they are also running
on this branch, then we run into the situation that unless we merge once
every few days we will miss new failures. Especially if we only merge
shortly before the beta build, it might make it impossible to build the
beta if it takes us a while to fix the failure. If on the other hand
treeherder builds run on m-b default, then they won't pick up patches
pushed to our branch to fix failures and could behave differently than
the final builds.

Moving towards a branch will also get us closer to freezing the mozilla
repo, which I want to avoid. If you don't have time to merge, or we
notice there are some incompatible changes on beta and we take the easy
route of not merging into our branch, then we could get stuck.

It will also be more work when doing the 6-week merges, although this
would probably just be a matter of adding code to the merge tools.

Generally, having a few patches atop the Mozilla repo is ok, but as this
patch queue grows it will be hard to maintain. I don't recall the exact
circumstances, but I remember colleagues at Sun using this technique for
something related to OpenOffice and complaining it was the worst idea
they ever had. Instead of adding one more repo with additional patches,
I think we should rather push to have patches accepted. From memory
there were few situations where patches were denied, but mostly because
we asked very late in the cycle and they didn't want to risk finding
regressions in rc1.


More information about the tb-planning mailing list