comm-central future as a branch
jorgk at jorgk.com
Tue Oct 9 23:57:44 UTC 2018
On 09/10/2018 10:06, Magnus Melin wrote:
> Quite often it's the case that Thunderbird code needs to be adjusted
> to build, due to changes in mozilla-central code. For cases of known
> incoming bustage Thunderbird now would have the possibility of waiting
> to do the merge until a fix is available. I would suggest never to
> back out bustage causing mozilla-central changesets from the
> comm/default branch, but to detect other incoming bustage by doing
> builds from a comm/band-aid branch (branced from comm/default). The
> details on this can be discussed later though, not to derail
> discussion about the main issue here. There are many alternatives, and
> it's also completely possible to do what we currently do.
So what is the "main issue" if not handling bustage less stressfully?
As the main firefighter I can tell you that waiting can be fatal, since
the next bustage can be in the next merge you're not doing since you're
waiting. Singular backouts could be attractive although their management
would become messy real soon.
So if we're delaying the merge, what would be the process to detect
bustage? Do the merge onto some other branch with which we run a try build?
More information about the tb-planning