SIMPLICIO: In the DB, that set of testcases required for an udpate to pass? We should keep them associated with a particular update -- with the updates table.

SALVIATI: Ah, but then our friend Sagredo the avid packager would have to re-enter his requirements every time he creates a new update.

SIMPLICIO: Huh. Ok, then we should keep them associated with packages. When a new update is created for a certain package, all the testcases normally required for that package are required for the update. Multi-build updates require the union of their packages' required testcases.

SALVIATI: But then every time Sagredo becomes the maintainer of a new package, he would have to specify the test cases for each new package.

SIMPLICIO: Then we can keep the set of test cases required for an update associated with the packages' stack. Every new package added to the stack inherits all the required test cases. If a multi-build update is composed of packages from more than one stack, it inherits all the required test cases of all the stacks of all the packages of all the builds that make it up.

SALVIATI: But then, what about all the packages that are not part of a stack? One-offs?

SIMPLICIO: This is hard.

SALVIATI: 🚲

Maybe a cascading system would be the most flexible:

• If a stack has requirements defined and no other requirements are defined, then those apply to the update.
• If a package has requirements defined, then those override the stack's requirements for that update.
• But a packager can also specify requirements on the update itself, overriding both package requirements and stack requirements. The stack/package requirements are simply presented as defaults when the update is created. The packager can edit the update at a later time to change the requirements if something comes up.

This way, say the packager knows an update is truly exceptional, they can override all other requirements for that update so that it will get pushed. (Similarly, a site admin or releng group member could login and change the requirements on a stuck but important update if it needs to get through.)

We could also have site requirements defined in config or something, to provide defaults to updates that have no others defined -- a baseline.

This seems really flexible to me. Coding the check would be pretty straightforward, but it would require a good bit of UI work to let people tweak requirements at all these different levels (stack, package, and update).

The cascading approach sounds sane to me. I wonder if we can just create a Mako function for the UI widget that can be re-used for stacks/packages/updates.

OK - a bunch of progress going on now in the branch.

Current status:

• when a stack is created
• when a package is created
• when an update is created
• write tests for all that cascading stuff
• do hub checks at push time to make sure required bits are happy
• write tests for hub check
• do app checks at request-for-stable time to make sure required bits are happy too
• write tests for request-for-stable check