Hi, So, Cyrus 2.5 releases have been taking me way too long.
2.5.1 was mostly delayed by learning the process and gaining access to things (unsurprising for my first release). 2.5.2 is being held up by writing release notes -- and chasing up user-level descriptions of what our changes are doing. This is made difficult partly by me only working on Cyrus a few days a week, and partly by me being in a timezone that means my working hours rarely coincide with other developers', meaning that everything I need to ask about ends up being a few days round trip. This means that when we decide "yes, we need to do a new release", the new release isn't making it out until like a week later -- not cool. So from 2.5.2 on, I'm going to be checking the cyrus-imapd-2.5 branch every day I'm on Cyrus, and drafting release notes for new commits as they appear. If I can't tell from the commit log or related maniphest task(s) how to distill your change down to something suitable for inclusion in the release notes (such as "fixed bug: no longer flurbl when condition"), I'll email you about it. Please respond promptly. I'll also be creating a "Release 2.5.x" task in maniphest for the next release as part of the release process. If it's critical that your change be included in the next release, please make sure it has an associated maniphest task, and mark it as blocking the Release task. When we decide that it's time to release, if there are commits on cyrus-imapd-2.5 that I don't already have and can't easily determine how to write a release note for, and the developer isn't responding to my email, and if they aren't marked as blocking the release, then I'm probably going to revert them, release, and then re-revert them (so they'll end up delayed till the next release.) But hopefully this won't happen that often. I don't think there's a problem with our commit messages -- they're generally pretty descriptive of what's being done, from a developer perspective, which is as they should be. But release notes are for users and need to be useful from their perspective, and it's not always obvious from a developer-centric commit message what the ramification for the user will be (especially when you're me and still learning the code base). Over time I'm hoping that we'll get to a point where commit messages and/or maniphest tasks generally just already contain a suitable description of their user-visible ramifications (if any), but I figure we'll work towards that rather than suddenly mandate it. Cheers, ellie