The created documentation from the pull request is available at: docu-html

Basically agreed in infrastructure planning session. Feel free to document your opinion here formally with a PR review!

Overall, this reads very well. I'm in support of this approach.

However, what I still don’t understand is how “coordinated multi-repo” works. Yes, I understand that the individual PRs shall be tagged with a common label. But how does the integration CI know that all PRs with that label are now present — more could still be added (or removed again, e.g. if I accidentally applied the wrong label and change it then); when is the changeset considered complete and the integration pipeline can run? Does it need a manual trigger? Do you use a time window of x minutes? Does the pipeline simply run for each individual PR in the coordinated set and simply fails n-1 times until the whole set (of n PRs) is there?

And then it would be nice if one could merge the entire coordinated set automatically with "one click" (if everything is green in each component as well as in the integration). In any case, we should strive for a way that ensures everything belonging to the coordinated set gets merged and nothing is forgotten, so that inconsistencies and non-"integrability" don’t creep back in. Maybe if you merge in one repo, then all PRs in all other repos that belong to the coordinated set are merged too?!

Overall, this reads very well. I'm in support of this approach.

However, what I still don’t understand is how “coordinated multi-repo” works. Yes, I understand that the individual PRs shall be tagged with a common label. But how does the integration CI know that all PRs with that label are now present — more could still be added (or removed again, e.g. if I accidentally applied the wrong label and change it then); when is the changeset considered complete and the integration pipeline can run? Does it need a manual trigger? Do you use a time window of x minutes? Does the pipeline simply run for each individual PR in the coordinated set and simply fails n-1 times until the whole set (of n PRs) is there?

Good points. There are some ways to do this technically in GitHub. I know it for "enterprise", I suspect it for "public". I would use "PR with head branch & base branch the same" as unique identifier. It can be the same on all participating repositories, can even be created automatically. Example:

• I open a PR on communication with HEAD foo and BASE main (draft as a start) and do some work.
• automation creates a draft PR on reference_integration. Due to that PR, CI runs whatever is required there. Automation creates feedback to my PR on communication. That feedback is made a required check to merge to main.
• It can now be that e.g. I need to open another PR with HEAD foo and BASE main on "baselibs" to fix a compilation / test failure on reference_integration. OK, exactly what I wanted.

(very rough sketch, just to convey the idea)

And then it would be nice if one could merge the entire coordinated set automatically with "one click" (if everything is green in each component as well as in the integration). In any case, we should strive for a way that ensures everything belonging to the coordinated set gets merged and nothing is forgotten, so that inconsistencies and non-"integrability" don’t creep back in. Maybe if you merge in one repo, then all PRs in all other repos that belong to the coordinated set are merged too?!

This is very tricky. In fact, we are right now trying to implement something like that internally on GitHub Enterprise - using only GitHub methods. I cannot yet say that this works; it's like an atomic merge which involves a set of "the same series of PRs". Ideally a merge queue, so that long-running CI is not a problem. Maybe it requires a third-party tool (some GitHub Bot) or some additional requirement (e.g. you must use a singular integration repository). I can report when I have results here.

(What I wrote here IMHO only expands on the proposal, should in no way contradict it. If it does, that is my lacking ability to explain my thoughts ;-))

* I open a PR on communication with `HEAD` `foo` and `BASE` `main` (draft as a start) and do some work.

* automation creates a draft PR on `reference_integration`. Due to that PR, CI runs whatever is required there. Automation creates feedback to my PR on communication. That feedback is made a required check to merge to main.

* It can now be that e.g. I need to open another PR with `HEAD` `foo` and `BASE` `main` on "baselibs" to fix a compilation / test failure on `reference_integration`. OK, exactly what I wanted.

(very rough sketch, just to convey the idea)

So, if I understand you correctly, basically what you are saying is: It will fail n-1 times until the n-th required PR is in place. I mean I can somehow live with it, but appears to me to be a waste of resources.

Maybe we can think of something that signals "this set of PRs is now complete and stable, now the integration pipeline will yield a sensible outcome". Ideally not (entirely) manual, because I still want automation as much as possible.

it's like an atomic merge which involves a set of "the same series of PRs".

Exactly. I had this term in mind but hesitated to write it down, since I don't think it's truly achievable (being truly atomic). But yes, that's probably the best term to use to convey the idea.

Maybe we can think of something that signals "this set of PRs is now complete and stable, now the integration pipeline will yield a sensible outcome". Ideally not (entirely) manual, because I still want automation as much as possible.

I think as long as the merge requires a passing CI (and you cannot "forget" to request this integration run) - should be fine!

it's like an atomic merge which involves a set of "the same series of PRs".

Exactly. I had this term in mind but hesitated to write it down, since I don't think it's truly achievable (being truly atomic). But yes, that's probably the best term to use to convey the idea.

Yes, I also doubt that truly atomic is possible. Best that is possible is something like "serializing the integration of groups of PRs via some queue", with "queue halts if there is a problem integrating one of the groups". And hoping that will not happen often. Maybe something is possible around "backing out failed integrations automatically" and "continuing with the next group" - but I can see already the complexity of that code exploding...