Release notes

[ellie timoney]

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