What about power this off?

This is not a package with a truckload of dependency tree, like systemd or cmake.
It is just Emacs and its Elisp auto-generated plugins - a single trunk with many leaves.

Also, Emacs is not a hidden-but-very-important core package like systemd or SDL. It is an app that the users directly call and execute in their PCs.

It is simply insane that each and every release - or even a mere bugfix - of Emacs require sending it to staging because of the mass rebuild of auto-generated plugins.
Worse, the plugin auto-generation is still buggy after two years - we work around this by removing the files before generating them.

Also, there is nothing on the Staging branch that would be useful for Emacs that can't be done on the Master branch. Emacs does not need bleeding-edge mass-rebuild-triggering software to be built - the same compilers and the same autotools needed to build any other text editor, or application for that matter, can be found on Master.

That being said, I suggest to remove the auto-generated Elisp packages from Hydra. The users can install these packages in their local PC-XT machines like they did in the good old times of Linux 2.4...

This is mostly about the number of rebuilds this causes, not about it needing anything that is on staging.

If the rebuilds of its reverse dependencies are so cheap, why not make them preferLocalBuild?

If the rebuilds of its reverse dependencies are so cheap, why not make them preferLocalBuild?

Can this be done on CI? If yes, then fine.

Maybe we could introduce some low-prio variant of the trunk jobset for such cases. It would get lower eval frequency, lower build shares (low priority), and channels wouldn't be waiting for it at all. We already have cross-trunk with these properties, though it's a specific area.