Patch set

A browser that behaves differently from the project it grew out of behaves that way because of a list like this. What the list does not name never reaches the sources, whatever files lie beside it.

A patch set is an ordered list of source changes applied to an upstream tree before anything is compiled.

The list is the thing that runs

A folder of patch files is not a patch set. The builder reads one list, top to bottom, and applies exactly what that list names.

1
New files arrive first
Files of our own that the project does not have are unpacked into the tree before anything existing is changed.
2
Changes go on in order
A later change may rely on something an earlier one introduced, so the order carries meaning of its own.
3
A name absent from the list does nothing
A file lying beside the list describes where work belongs and never reaches the tree by itself.

How large this set is

The set changes 39 files of the Chromium tree and brings 10 files of its own.

Both numbers are counted from the list rather than from the folder, so a change that is described and never applied is counted as nothing.

Applied has to mean removable

The return code of the tool that applies a change proves very little, because a tree keeps moving after the change lands and before compiling starts.

So the question asked instead is whether the whole change can be taken back off the tree. A piece that cannot be reversed was never fully there.

Every piece counts
A change is judged whole, so one hunk missing from the tree fails it exactly like a missing file.
An empty list is a failure
Nothing to verify has to read as a problem rather than as a clean result, or the check guards emptiness.
A placeholder stops the build
A skipped change would leave an ordinary browser carrying our name and passing for ours.

One owner per file

Two changes reaching into one file leave the second unable to land as soon as the first is adjusted. The rule keeps every file the business of a single change.

A thin line in a foreign file
Where a change has to touch upstream code it leaves one call, and the body of the rule lives in a file of ours.
Retiring a layer is part of the work
When the engine takes over a surface, the temporary layer above it is removed rather than left to argue with it.

Why rebasing is the real cost

The change is cheap and the rebuild is not. Every Chromium milestone moves the lines a change is anchored to, and every system is compiled again from the top.

So the set stays small and every addition has to earn a place in it.

Often confused with

A launch switch
A switch changes how a finished browser starts and stands in plain sight in the process command line.
An extension
An extension runs inside a browser that is already built and reaches only what that browser hands it.
A build setting
A setting chooses how the sources are compiled. A change chooses what the sources say.

What this does not do

It does not change a browser you already have. The work happens before compiling, so it reaches only a binary built from those sources.
It does not cover a surface it does not name. What is missing from the list is missing from the browser, whatever a neighbouring file describes.
It does not carry itself onto a new milestone. New sources have the set applied again, and a change that will not apply stops the build instead of being dropped.
It does not hide the real font inventory from a lookup by unique name. Measurement there is narrowed by the profile list, and closing the lookup needs a further change.

Check it

Each line above is a file you can open and a stand that keeps it honest.

The list the builder executes in order: engine/patches/series
A placeholder in the list is refused rather than skipped: apps/desktop/test/engine-patches-real.js
A change counts as landed only when the tree gives it back whole: engine/scripts/сверка-правок.sh
Every declared capability is read out of the patched tree: engine/scripts/опись-умений.js · apps/desktop/test/опись-умений-снимается.js

Questions

Why not change the browser after it is built?: Because the answer a page reads is produced by compiled code. A value replaced above that code is itself a value, and a page that asks twice gets two stories.
How do I know a change really landed?: Every capability the engine declares is read back out of the patched tree by a marker the change leaves there. A capability with no marker is not declared at all.
What happens when a change will not apply?: The build stops at that point. Carrying on without it would produce a browser that looks like ours and shows a site the real machine.
Does a bigger set mean a better browser?: No. Every change has to be moved onto new sources at each milestone, so the set grows only where a page can read the difference.
Can I look at the list myself?: Yes. It is a plain text file in the repository, and the check block below names it along with the stand that keeps placeholders out of it.

Next to this

See the set in the build that ships

The engine page lists every surface the set covers and names the stand that measures it.

Download ARMANOS Our browser engine