Three issues in this plan already depend on a list of platforms, and no issue
creates it. The build workflow covers "the platforms the release will later
target". The suite runs on "every platform the release ships a binary for". The
release workflow produces a binary "for each platform the build already covers".
All three point at a set nothing fixes, which is the same defect as a failure
message naming a file that is not in the tree.
Fix the set here, before the first workflow is written against it.
The list is decided from what the runner does rather than from what is
conventional. The runner reads a checkout, and the parts of that job which
differ between machines are what earn a place on the list: whether the filesystem
folds case, what separates a path, and what a line ending arrives as. A platform
that differs in all three is a platform the suite has to run on. A platform that
differs only in processor architecture is a platform the release has to build
for, and running the suite there buys much less. The record says which of the two
each entry gets, because the two costs are different and collapsing them is how a
matrix quietly doubles.
The first constraint is contributors. Somebody writing an experiment record runs
the checker before pushing, and a platform with no binary is a platform whose
contributors cannot run the gate they are held to. The second is where the checks
themselves run, since a platform the hosted runners do not offer is a platform
this repository can build for and cannot test on, and the record should say that
out loud rather than leaving a green board to imply coverage that does not exist.
The cost of each entry is worth writing down next to it. Every platform on the
list can hold a merge on its own, and a platform nobody uses produces failures
nobody acts on, which teaches readers that red is survivable.
What was considered and rejected. Building everything the toolchain can target,
rejected because the list would then be a property of the compiler rather than a
decision, and because most of those entries have no contributor, no runner and no
way to reproduce a failure. Building for one platform only, rejected because the
case-folding and line-ending differences are exactly the defects the checker will
have, so a single-platform release ships a tool that cannot read its own
repository on the machines its contributors use.
Done when docs/decisions/0012-the-supported-platforms.md exists on the default
branch, names each platform, says for each whether it gets a build only or a
build and a suite run with the reason, names the platforms this repository can
build for and cannot test on, states what each entry costs, and the build
workflow, the platform suite and the release workflow name exactly the platforms
that record names and no others.
Three issues in this plan already depend on a list of platforms, and no issue
creates it. The build workflow covers "the platforms the release will later
target". The suite runs on "every platform the release ships a binary for". The
release workflow produces a binary "for each platform the build already covers".
All three point at a set nothing fixes, which is the same defect as a failure
message naming a file that is not in the tree.
Fix the set here, before the first workflow is written against it.
The list is decided from what the runner does rather than from what is
conventional. The runner reads a checkout, and the parts of that job which
differ between machines are what earn a place on the list: whether the filesystem
folds case, what separates a path, and what a line ending arrives as. A platform
that differs in all three is a platform the suite has to run on. A platform that
differs only in processor architecture is a platform the release has to build
for, and running the suite there buys much less. The record says which of the two
each entry gets, because the two costs are different and collapsing them is how a
matrix quietly doubles.
The first constraint is contributors. Somebody writing an experiment record runs
the checker before pushing, and a platform with no binary is a platform whose
contributors cannot run the gate they are held to. The second is where the checks
themselves run, since a platform the hosted runners do not offer is a platform
this repository can build for and cannot test on, and the record should say that
out loud rather than leaving a green board to imply coverage that does not exist.
The cost of each entry is worth writing down next to it. Every platform on the
list can hold a merge on its own, and a platform nobody uses produces failures
nobody acts on, which teaches readers that red is survivable.
What was considered and rejected. Building everything the toolchain can target,
rejected because the list would then be a property of the compiler rather than a
decision, and because most of those entries have no contributor, no runner and no
way to reproduce a failure. Building for one platform only, rejected because the
case-folding and line-ending differences are exactly the defects the checker will
have, so a single-platform release ships a tool that cannot read its own
repository on the machines its contributors use.
Done when
docs/decisions/0012-the-supported-platforms.mdexists on the defaultbranch, names each platform, says for each whether it gets a build only or a
build and a suite run with the reason, names the platforms this repository can
build for and cannot test on, states what each entry costs, and the build
workflow, the platform suite and the release workflow name exactly the platforms
that record names and no others.