Update April 2, 2026:

The launch of Project Unity has been postponed to April 1, 2027. The proof-of-concept completed its first full invocation on March 14. Every target built. Every test passed. The CI dashboard, for the first time in the recorded history of the project, is entirely green. No flaky tests. No intermittent failures. No unexplained segfaults. Nothing. The Fellowship has spent the past two weeks attempting to determine what has gone wrong. A build system that has never once produced a fully clean run across all targets does not simply begin doing so without cause. Purdie has recommended that no changes be merged until the anomaly is understood. Halstead has taken the autobuilder offline as a precaution. Knight has requested that nobody speak of it until further notice. The investigation continues.

________________________________

Background

For over a decade, the Yocto Project autobuilder has grown organically. What began as a manageable set of build targets has expanded into a sprawling matrix of architectures, BSPs, images, SDKs, and runtime test configurations — each with its own scheduling, resource allocation, and failure modes. The infrastructure has served us well, but maintaining it has become increasingly costly in both human effort and compute resources.

Over the past year, a pattern has emerged in TSC discussions: build failures in one configuration frequently mask failures in others. Flaky tests in one target cause cascading delays across the entire
matrix. Bisection is complicated by the sheer number of independent build jobs. The system, in short, has become fragmented — and that fragmentation is the root cause of many of our most persistent reliability issues.

Joshua Watt was the first to quantify the scope of the problem. His analysis of autobuilder logs from the past eighteen months showed that approximately 34% of developer time spent on build failures was attributable not to genuine regressions, but to infrastructure fragmentation — resource contention between parallel jobs, inconsistent environment state, and scheduling race conditions that would not exist in a unified build.

The Council

The matter was formally raised at the TSC meeting on February 19, 2026, chaired by Alexander Kanavin. The discussion — which Kanavin later described as “longer than any reasonable meeting should be” — ran for nearly four hours and involved every active TSC member and several invited contributors.

The core question was deceptively simple: could the autobuilder’s reliability problems be solved by eliminating the matrix entirely and building everything — every architecture, every BSP, every image, every SDK — in a single, sequential, monolithic build invocation?

Opinions were divided.

Richard Purdie, who has maintained the autobuilder infrastructure for longer than most contributors have been involved with the project, spoke at length about the historical context. “I’ve seen build systems come and go,” he noted. “Fragmentation always seems like the right approach until you’ve spent fifteen years watching the pieces drift apart. There’s something to be said for keeping everything in one place — where you can see it, where you can control it.” He cautioned, however, that the path would be long and that those who undertook it might not fully understand the burden until they were well along it.

Mark Hatle, who had been largely absent from recent TSC discussions due to other commitments, returned for this meeting and surprised several attendees by voicing strong support. Hatle pointed out that he had maintained unified build configurations for internal use at his previous employer for years, and that the approach was not as impractical as it might appear. “This is not a new idea,” he said. “It’s an old one whose time has come back around.”

Not everyone agreed. Philip Balister was openly skeptical, arguing that the compute requirements alone made the proposal impractical. “You are talking about a build that could run for days,” he warned. “The infrastructure costs would be enormous, and I am not convinced the reliability gains would materialize.”

Nicholas Dechesne took a different position. He agreed that consolidation was necessary, but argued that the resulting unified build should be directed toward his own multi-architecture validation efforts specifically. “If we are going to build everything, we should build it where it is needed most,” he said. He returned to this point several times throughout the discussion, each time with increasing conviction. Kanavin eventually asked him to table the proposal for a future meeting.

Andy Wafaa was initially dismissive, calling the idea “a solution in search of a mandate.” By the end of the meeting, however, after reviewing Watt’s data more closely, he reversed his position and agreed to support a trial run. “I don’t love it,” he said, “but I cannot argue with the numbers.”

Ross Burton, notably, did not attend the meeting. It was later learned that Burton had been independently developing his own build consolidation prototype — a highly optimized but architecturally incompatible approach that he had not shared with the TSC. When informed of the Council’s decision, Burton reportedly expressed displeasure, stating that his approach was “superior in every measurable dimension.” The TSC acknowledged his work but declined to adopt it, citing concerns about long-term maintainability and philosophical differences in design.

The discussion concluded with a unanimous decision — Balister abstaining — to proceed with a proof-of-concept. The question of who would lead the implementation proved more contentious than the technical decision itself.

The Fellowship

Several senior contributors immediately volunteered, but Purdie argued that the project lead should be someone who could approach the problem without the accumulated assumptions that come with years of autobuilder experience. The role ultimately fell to Megan Knight, a relatively recent contributor to the project’s build infrastructure. Knight was initially reluctant but accepted after Michael Halstead agreed to serve as co-lead, providing the operational continuity that the project would require.

“I wouldn’t have said yes without Michael,” Knight acknowledged. “He knows the autobuilder infrastructure better than anyone. Wherever this goes, it doesn’t go anywhere without him.”

The full implementation team — internally referred to as the “Fellowship,” a name that stuck after Halstead used it in an offhand IRC comment — consists of nine members:

• Megan Knight — Project lead, build configuration design
• Michael Halstead — Infrastructure and operations
• Richard Purdie — Advisory role, BitBake integration
• Mark Hatle — Legacy configuration migration
• Paul Barker — Test framework integration and flaky test identification
• Tim Orling — Hardware BSP consolidation
• Nicholas Dechesne — Multi-architecture validation (scope limited to the unified build, despite ongoing requests to expand it)
• Thomas Roos — Contributor tooling and developer experience
• Marco Cavallini — Contributor tooling and developer experience

Roos and Cavallini, it should be noted, were not part of the original TSC decision. Both independently approached Knight after the meeting and asked to be included. Their enthusiasm, while not initially solicited, has proven valuable — particularly in areas of the build system that other team members had considered peripheral.

Barker and Orling have developed what can only be described as a productive rivalry over whose platform support layer causes more build failures in the unified configuration. At last count, Orling’s hardware BSPs lead by a narrow margin, a fact that Barker has mentioned in no fewer than three status emails.

Technical Approach

The unified build is implemented as a new bitbake multi-config configuration that chains every supported MACHINE, DISTRO, and image target into a single dependency graph. A new DISTRO_FEATURES flag enables the mode:

DISTRO_FEATURES:append = " unity"

When enabled, the build resolves the complete set of targets across all registered configurations. The resulting dependency graph is, to
our knowledge, the largest single BitBake invocation ever attempted.

Key configuration parameters are set in unity.conf:

# Project Unity - Unified Build Configuration
UNITY_MODE = "1"

# Build everything. In sequence. On purpose.
UNITY_TARGETS = "all"

# Estimated completion: see UNITY_ETA
# UNITY_ETA: Uncertain. Do not ask.

# Abort on failure: no. We see it through.
UNITY_ABORT_ON_FAILURE = "0"

# Resource allocation
UNITY_BB_NUMBER_THREADS = "1"
UNITY_PARALLEL_MAKE = "-j1"

# This is deliberate. Do not change this.
# We tried higher parallelism. It is not safe.

The single-threaded configuration is not a placeholder. Early testing with parallel execution produced nondeterministic results that the team was unable to fully diagnose. Knight made the decision to
serialize execution entirely, noting that “reliability is the goal, not speed. If we wanted speed, we would not be here.”

Current estimated build time for a full Unity invocation on the reference hardware is approximately nine days.

Current Status

The Fellowship has been working on the proof-of-concept since early March. Progress has been uneven.

Purdie provided critical guidance during the initial BitBake integration phase but has been intermittently available since, resurfacing periodically with detailed technical recommendations that have proven consistently correct despite limited context on recent changes. Knight has described this pattern as “frustrating but ultimately indispensable.”

Hatle’s legacy configuration expertise has been essential in resolving compatibility issues with older BSP layers that the current team had limited experience with.

The most significant setback occurred in mid-March, when Dechesne submitted a series of patches that expanded the Unity build scope to include several additional multi-architecture validation targets. The
patches were technically sound but outside the agreed scope. After a lengthy discussion, the patches were reverted, and the scope was formally documented to prevent further expansion. Dechesne accepted the decision gracefully but noted that “the offer remains open.”

Next Steps

The proof-of-concept is expected to complete its first successful full build by mid-April. If the results validate Watt’s analysis — specifically, a measurable reduction in infrastructure-attributable failures — the TSC will consider adopting Project Unity as the default autobuilder configuration for the next release cycle.

A more detailed technical report will follow. In the meantime, the team welcomes questions and feedback on the yocto-dev mailing list.

The build continues.

________________________________

Project Unity is a collaborative effort of the Yocto Project Technical Steering Committee. The views expressed in this post represent the consensus of the TSC and the Fellowship team members, who have given their consent to be quoted.