Well, it’s a strawman proposal, so everything subject to change. We could exclude leaf modules. But that wouldn’t really solve any grand problems. Calendar is part of core, so it does block the overall GNOME release. Some hypothetical examples of leaf modules causing problems:
- Library you depend on breaks API, fix is committed to gnome-calendar git master a day or two later, but not released. Release team does not notice until trying to build release, when we’re in headless chicken mode.
- Meson gets a bit stricter. Fix is committed to gnome-calendar git master, but not released. Release team again does not notice until headless chicken mode.
- Vala or GCC changes something. Fix is committed to gnome-calendar git master, but not released. More release team headless chickens.
These scenarios should be familiar. Pretty sure Calendar has failed to build in releases more than once. There’s just no way to predict what will go wrong when modules miss the tarball deadline. We can’t really notice in advance because there’s just no way to predict what will break when building from the latest releases until we see what has released and what has not. We could set up a “tarball CI” to build the latest tarball of everything and verify that it works, but that would probably be useless because it will work fine until release week, then everything will break all at once and we’ll wind up exactly where we are right now.