User:Asasaki:MBMerge

This page tracks a list of reasons why we should merge mobile-browser into mozilla-central.

Improved regression detection

Tree-mgmt regression script

• mozilla.dev.tree-management talos regression detection only deals with one repo
  • To add multi-repo support, we would have to not only update the script, but graphserver, talos, and our buildbot automation.
  • The fastest route to detecting all changes for a regression/improvement would be to merge mobile-browser in.

Bisecting

• Tools like hg bisect allow for finding when a bug first appeared in code.
  • Two repositories means additional complexity
  • The fastest solution is to merge mobile-browser in.

Correlation of mobile+mozilla changes

• Mercurial, like all modern revision control systems, allows for a single revision to specify a body of code
  • Two repositories breaks this; to determine source for any particular time or build requires additional tools/mapping
  • The fastest solution to map a mobile change with a specific m-c change (and vice versa) is to merge in.

Improved branching mechanics

No more "moving target" code integration

• When working on a project branch, the code/pull/integrate/merge workflow allows for granular changes to code that is internally consistent + working.
  • Following multiple heads as your source, where one of the heads is outside of your team's control, creates a moving target that breaks this model.
    • It adds a layer of complexity to determine why something broke
    • Forces integration at times which may not be convenient or even possible for your team
  • The fastest way to restoring this model is to merge mobile-browser in.

No more dual-landing with bustage in between

• Large or complex patches often need changes in multiple areas of code that are interdependent.
  • Landing one of these patches without the other results in tree bustage. It's difficult to time simultaneous landings; interdependent multi-repo landings are therefore riskier to land.
  • The fastest way to solve this is to merge mobile-browser in.

Double- and triple- landings easier

• As we move further to a multiple project- and release- branch model, the chances of needing to double- or triple-land (or more) patches increases.
  • With mobile-browser merged in, this is double- or triple-landing
  • Without mobile-browser merged in, if the code affects both mobile-browser and platform, double- or triple-landing becomes quadruple- or sextuple-landing, with chances of out-of-sync repo bustage for each set of landings.

Self-contained branches

(Where branch == hg repository)

• By keeping each project+release branch self-contained, each can have separate schedules for both refreshing the code base and merging the branch back into the main code line.
  • Risky patches can be contained within one branch until they're ready for integration.
  • Similarly, risky patches [landed in other branches] need not be taken in a branch until they have time/headspace to refresh the code base.
  • This is a corollary to avoiding "moving target" integration.

Easier project branches

• In our new faster cadence, we're going to be relying heavily on a large number of project branches and several active release branches.
  • The above mentioned separation and isolation allows non-mobile teams to be more agile without "moving target" integration
  • This separation also allows the mobile teams to work on completely separate branches with different schedules.
  • Having this separation of project branches without merging mobile-browser in would double the number of active branches in this model.

Straightforward release branching

Faster release cycles

• When dealing with fast release cycles, sometimes you need to make fast branching decisions
  • The lack of separation between branches adds complexity to these decisions
  • Needing to freeze not one, but two branches adds strain on the various teams

Risk minimization

• To minimize risk, we need to know a) the scope of a change and b) that no other changes affect our release branch.
  • Keeping release branches self contained help minimize and limit scope
  • Merging mobile-browser in helps keep our release branches self-contained.

Multiple concurrent releases

• If there are multiple concurrent releases happening, the branching scheme becomes more complex
  • Having to track a second repo at the same time adds complexity
  • Multi-repo multi-branch landings add complexity, especially with divergent codebases where the patch doesn't apply cleanly.

Reduced mobile-specific support overhead

Faster mobile automation ramp-up

• Some of the mobile automation complexity is due to differences between the desktop and mobile configurations/behavior.
  • Reducing these differences to 0 would result in being able to piggyback any mobile changes on any desktop changes.
  • Reducing these to any degree would speed up additional mobile automation.
  • The addition of a second repository isn't just a one-time-hit; in addition to a step to check out a 2nd repo, we need to track a second revision, determine how to differentiate m-c+m-b versus tm+m-b or whatever combination in config files/database tables/across different toolsets/different script codebases.
  • Reducing to a single repository, like desktop, wouldn't remove mobile-specific packaging or signing or update behavior from the picture. But it would have a larger-than-expected reduction in complexity that would speed up automation work.

Tighter infrastructure integration with desktop

• In the past, desktop infrastructure changes have outpaced mobile infrastructure changes, which leads to code paths diverging.
  • Tighter integration means desktop improvements can "ride-along" to mobile infrastructure if desired.
  • Tighter integration also means that releng team members familiar with desktop infrastructure will be more willing/able to fix mobile infrastructure bugs.
  • There are a number of ways to get tighter integration with desktop infrastructure, but separate repositories is one of a number of reasons these differ.

Simpler -> more stable

• There are a number of workarounds and hacks to get the multi-repo infrastructure working relatively seamlessly in code that assumes a single branch.
  • These work, when done properly. However, reducing complexity and removing hacks helps remove other bugs that are introduced by those hacks+workarounds.
  • Also, fewer things are likely to break when modifying code that has fewer workarounds in it.
  • Merging in will remove the multi-repo workarounds we have in the mobile infrastructure.

Improved tryserver integration

Single try repo maps well to a single source repo

• The try repo is a clone of mozilla-central.
  • Because of this, there is no straightforward way to fully integrate mobile into try builds.
  • Mobile is currently "tacked on" to try and it's definitely obvious to people who want to use mobile try builds in any sophisticated way.

Get rid of the mobile repo special file

• According to John Ford's blog post the way to build against anything other than the default tip of mobile-browser is to check in a special mobile-repo and mobile-rev file.
  • This is certainly a way to solve this issue, but is an additional layer of complexity on top of the existing try process.
  • The best solution here is to merge mobile-browser in.

Build against a known revision of mobile code

• When using Try, you're building against a moving target of mobile (see above). This makes your mobile results less trustworthy, unless you force mobile revisions, which adds a layer of complexity.
  • Merging mobile-browser in would allow you to build against a known state for all code.