The Flutter Buildroot and the Engine used to live in a common repository. In 2016, in order to facilitate building the Flutter Engine in the Fuchsia as well Flutter buildroots, the buildroot used by Flutter was separated into its own repository with the engine DEPS file referencing the version of the buildroot to use. The Flutter Engine GN rules had to be written such that they worked when the engine was present in either buildroot.

Flutter no longer builds in the Fuchsia buildroot. Instead, Fuchsia artifacts are built from the Flutter buildroot using the Fuchsia SDK (which was not present at the time the split occurred) and vended to Flutter application authors. So, the original use case of the split is no longer present.

Even though there is no use-case served by the split, there are numerous downsides to this approach:

• Patches to GN rules (especially in the secondary buildroot) need to be split across multiple commits to the buildroot and the engine.
• Any buildroot patch necessitates a DEPS update in the engine.
• If the DEPS update fails for any reason, the same patch must be backed out in the buildroot ASAP. If someone else patches the buildroot in the meantime, they must hold till the failed buildroot update has been reverted lest their DEPS roll fail too.
• The buildroot has no presubmits. Authors who want to test buildroot updates must first update the buildroot in their fork and then point the patch that rolls DEPS in the engine to point to their fork of the buildroot so that presubmits can run. Before landing, they must back out this redirection after landing the patch in the buildroot.
• The separate PR queue for buildroot patches means the patches there are often missed by reviewers.

Personally, I dread instances where I have to update the buildroot. Not because it is hard, but because it is incredibly tedious. And quite unnecessarily so. The buildroot itself is a significant source of technical debt and having build rules split across two repos also makes incrementally tackling this debt hard. Merging the repos would get rid of one source of unnecessary complexity in the build process.

The buildroot has no presubmit or its own issue tracker, so I don't expect any infra related issues with this switch.

The original split occurred by preserving no history. The team has grown significantly since then and the Git history may be valuable. So maybe we should consider a subtree import instead of just copying over the files. But, I don't have a strong opinion either way.