Please remember that if your software is in GNOME core, GNOME SDK, or is a dependency of either: following the unstable release schedule for .alpha, .beta, .rc, and .0 releases is MANDATORY unless your project has no noteworthy changes. (For stable releases other than .0, please ignore the schedule and release whenever you feel a release is needed.)
If you are unable to release according to the unstable schedule, please contact the release team for help BEFORE the tarball deadline. Alternatively, if you no longer have time to handle unstable releases, then please consider removing yourself from the doap so we know that your project is not maintained and not to bother you about it.
Each unstable release, we spend several days dealing with build failures caused by missing releases. If you don’t release according to the schedule and your software fails to build or is responsible for other software failing to build, you will be contacted by release team asking you to IMMEDIATELY release, and we may release your module for you if you don’t respond IMMEDIATELY. This is zero fun for us or for you, and I have lost track of how many times it’s happened so far this week: three time so far just today, several more yesterday, several more the day before. We cannot wait even a short while for your module to release because we have hundreds of tarballs to build and will take ages to successfully release if we wait even a short while for late tarballs.
You can avoid almost all of these problems by simply releasing your tarball according to the schedule. Build failures are almost always already fixed in git and are just awaiting a release. See also: Emmanuele’s proposal to release everything automatically.
Also note that if we release for you on short notice, we’ll probably not do as good a job as you would. We might use a different version number than you would prefer, we might write worse NEWS than you would (if we write any NEWS at all), we’ll certainly fail to sign your tag since GPG is hard, we might fail post-release version bump if we don’t check the history carefully enough, we’ll comment out any tests that don’t work for us rather than try to fix them, and we’ll ignore any project-specific release instructions, READMEs, etc. Usually everything will go OK anyway, but it’s just better for maintainers to handle releases when possible.
If you need help to release and contact us before the deadline, then we have time to figure out these things. But after the deadline, we’re in a rush to move on to the next tarball.
And thanks to the magic of timezones, when we do notice it may be at at a very inconvenient time for you, like Friday evening, or the middle of the night…
I left a comment in Emmanuele’s topic to explain why we cannot detect these problems in advance: our normal CI can catch all problems except missing releases, but there’s no way to prepare for missing releases until the release deadline has passed, at which point everything is broken until we’ve responded to each missing release one at a time.
I don’t know if it’s already done, but when a release team member does a release commit in a module, a message could be copy/pasted with the explanation (now just a link to this page would be good enough), to avoid a bad surprise when the maintainer does a git pull.
By explaining that things can be fixed up afterwards if not done well (the NEWS file, version number, the README, etc).