A wild idea. Releases a collaborative effort, where maintainers are actually fairly invested in getting in the best .0 possible, and are working with you towards a goal.
Another wilder idea, people generally don’t like being enforced, and maintainers would also get unhappy if a release is cut in front of their faces, missing things they felt important. If a release missed the deadline, it’s not just because writing a NEWS entry is tedious.
While there might be theoretical benefit in a pencils down period, its usefulness gets quite watered down with CI, and I find a too long freeze period to be counterproductive. There’s already tens of patches in Mutter and GNOME Shell awaiting a freeze exception to be made and approved, or the freeze to be lifted. These are issues that maintainers do know may hinder the perception of the final release, and yet we have to make these requests, re-explain the issue and argue why we think it’s better merged than out.
Sure, “asking is not much”, “it’s hard to not get approved”, but truth is we drag our feet in this way for a full month each year split in 2 cycles, and issues do also not get approved (inexplicably, anything goes after .0, we even occasionally need brown bag stable module releases, but no biggie).
There’s also the question about what maintainers/developers do with that period. Some nothing, some turn to doing docs and tests, others branch early and never look back to the stable branch. Do any of these help with the public perception of the incoming .0?
I agree with Philip’s proposal, we should look at improving the management of stable branches (perhaps look at the infrastructure of other projects like Mesa). With early branching and (mostly) automatically managed backports, the freeze period would be pretty much moot.
Short of that, I think a deadline on a fixed timestamp just wishes delayed module releases away, and is vastly incompatible with them. I think it would create a lot less friction if you considered the .rc tag the moment the freeze applies to a module.