in which milo view? If it is the console, the order of builders there is inherently manual (because category cannot be computed), so one can just put the parent builder as the first one.

Yes, the console. To clarify, you are suggesting that we make two subcategories, "parent" and "child" and have all child builders in the child category? And that we get to control the order of the categories?

to be clear, you always control the order. It is defined by the order of "builders" entires in the console definition. Consider a definition:

  builders {
    name: "buildbucket/luci.chromeos.ci/master"
    short_name: "master"
  }
  builders {
    name: "buildbucket/luci.chromium.ci/child1"
    category: "cat1"
    short_name: "a"
  }
  builders {
    name: "buildbucket/luci.chromium.ci/child2"
    category: "cat1"
    short_name: "b"
  }
  builders {
    name: "buildbucket/luci.chromium.ci/child3"
    category: "cat2"
    short_name: "a"
  }
  builders {
    name: "buildbucket/luci.chromium.ci/child4"
    category: "cat2"
    short_name: "b"
  }


it will look like this

+---------------------
|          |cat1|cat2|
|  master  +---------+
|          |a|b |a|b |
+--------------------+
|          | |  | |  |

Generating that config should be straight forward for us.

But, what happens to a builder not listed in the console definition? We add / remove child builders relatively frequently, and I'm worried about transitional issues.

adding/removing a builder involves a config push. Updating a console is also a config push. Why can't both be done in one commit?

If I remove a release builder (dead-release) while there is an in-progress release build, will the in-progress build of "dead-release" still be visible in the UI? The console view specifically? What about historical builds of it?

If we move experimental builds between two consoles (which can be considered a remove, and an add) this becomes more important.

if a release builder is removed from a console def, that console will stop displaying it that builder column.

even definition of a builder is removed, today a user cannot load historical builds in builder view (e.g. https://ci.chromium.org/buildbucket/luci.chromium.try/no_such_builder). We can change that. Milo would say "This builder is not defined, but I've found some builds, here".

Buildbucket does not consult builder definitions in search. Today one can search historical builds of deleted builders. Buildbucket consults builder definitions only during build creation.

Retitling to clarify that the work is on CrOS side when we go to generate the config.