Release Plans, patches, upcoming

[Bron Gondwana]

On Fri, Aug 10, 2007 at 12:06:15PM -0400, Ken Murchison wrote:
> David Carter wrote:
>> This sounds like a plan. For the time being I am using the first 11 bytes 
>> of message MD5 sums on my Cyrus 2.3 systems, just like Fastmail.
>> It would be useful to have a migration route to full 20 byte SHA1 UUIDs. 
>> Zero padding existing schema 1 and schema 2 UUIDs is probably good enough.
>
> I'm going to leave this stuff out of 2.3.9 and add it in for 2.3.10.

Fair enough.  We'd love to see a 2.3.9 soonish and have an idea of the
timeframe for 2.3.10.  I think having an idea of when patches need to be
ready for suggested inclusion into the next version would push us to
make the effort to try and test things rather than pushing them down the
queue!

Just a quick idea of what's coming up in what we'd like to do with
Cyrus:

* cyr_synclog - patch exists and is working but I haven't pushed it out
  to the website.  Allows you to add a record to the sync/log file using
  the Cyrus API (rationale: we used to call an explicit sync_client -u
  when creating a user but if the replica was down this failed, and then
  if we had to fail over the user didn't exist.  Crappy.  Especially if
  this was the result of a migrate rather than a brand new user)

* standardised/parseable logging format allowing full tracing of the
  message lifecycle:

  * include uid and uuid of lmtp message delivery along with messageid
    and same for upload or copy.
  * reply to LMTP session with disposition information (duplicate,
    rejected, forwarded, delivered, etc)  *THIS FOR FAILURE REPAIR*
  * sieve extention to allow inserting arbitrary identifiers into the
    log so you can tell which path the delivered message followed
    through the script (in association with our auto-sieve generator,
    allow both statistical reporting and complete "daily report of
    email activity on your account" information to be generated for
    people who want/need it)

* retain SEEN state for expunged messages

  * more deeply, a standard interface allowing you to iterate over
    both the expunged and non-expunged records in the mailbox.  This
    is a little trickier and hence probably longer term, but that's
    now the only piece of meta-data that's really hard to restore
    after an accidental delete.


I'm sure there are others sitting around in the ether, but that's my
current top list of things to do with Cyrus (other than making sure
Fast Rename is usable in our environment and hopefully adding a bit
more safety somehow, even if I have to do something godawful like
create a rename.db where you insert a record saying you're about to
start a rename and delete it once you've confirmed it's safely
finished or rolled it back)

Bron.