Fabian Meumertzheim

Stack traces and the profile to me look indistinguishable from a build that just waits for long-running actions to finish (but of course they are taking very long). If possible,...

@bazel-io flag

It didn't do anything on Windows before the revert: https://github.com/bazelbuild/bazel/commit/a9525c701125664bb9daf5637084e85dff186d31#diff-b572d41bff84fa61b397e97467a898b32baf118421a0b06859e3fa04c556a7ebL219 I don't know how it works, but maybe this `if` should be brought back?

Since we already have a mechanism for this (`max_compatibility_level`) that can also be used to make claims about compatibility with future versions (e.g. set it to a year), I think...

> The issue there is that bzlmod design follows the Go package manager design which presumes you can include two major versions to fix a diamond dependency problem, which is...

> But other modules which depend on absl but not affected by the breaking change would either unnecessarily fail due to a different compatibility level was chosen or have to...

Do we have examples of the line of breaking changes that absl has or is planning to make? Similar for protobuf. That could help us make a more informed decision.

Since max versions are inherently incompatible with the MVS approach, I would go as far as suggesting that we should close this as a duplicate of #25214 and fold its...

This looks reasonable to me, thanks for working it out. Could you send it as a PR so that we can properly discuss it?

I sent https://github.com/bazel-contrib/rules_fuzzing/pull/258 to give Bzlmod users a way to reference this engine without reaching into internal extensions. We would need to update the OSS-Fuzz build scripts in lockstep or...