Cyrus IMAPd 2.3.12 Released

I am pleased to announce the release of Cyrus IMAPd 2.3.12. 
This
release should be considered production quality.


Noteworthy changes:

* Added statuscache.db to cache IMAP STATUS data which
significantly reduces the amount of I/O necessary when
neither the
mailbox nor Seen state has changed -- courtesy of
Fastmail.fm
* Added option to unexpunge to restore messages by time
interval --
courtesy of David Carter
* Implemented undocumented IMAP SCAN extension, which
allows
Pine/Alpine to do cross-mailbox searches -- based on work of
David Carter
* Implemented incremental squat updates (see squatter.8) --
courtesy of
David Carter
* Fixed major bugs in reconstruct -k implementation --
courtesy of David
Carter

For full details, please see doc/changes.html and
doc/install-upgrade.html which are included in the
distribution.

URLs for this release:
ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.12.tar.gz

or
http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3
.12.tar.gz


Questions and comments can be directed to
info-cyruslists.andrew.cmu.edu (public list), or cyrus-bugsandrew.cmu.edu.

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

On Mon, Apr 21, 2008 at 07:35:01AM -0400, Ken Murchison
wrote:
> I am pleased to announce the release of Cyrus IMAPd
2.3.12.  This
> release should be considered production quality.

http://cyrus.brong.fa
stmail.fm/

Notable changes:

* cyrus-findall-txn-2.3.12.diff
  
  Creates a mboxlist_findall_txn function which takes a
transaction,
  allowing you to use it within a transaction.  This is a
little
  "shutting the barn door" now that we have
skiplist fixes for the
  same issue, but I think it's still valuable from a
correctness
  point of view.

* cyrus-fastrename-2.3.12.diff

  Update the fastrename patch to use mobxlist_findall_txn
when
  searching for inferiors and throughout all the rename and
delete
  paths for mailboxes.

* cyrus-folder-limit-2.3.12.diff

  Basically just updates the folder limit patch to use the
new API
  from the previous two patches, passing the transaction
down.


Other than this, it's basically the same old patches
refreshed
against 2.3.12, and of course everything that's been
accepted
upstream is removed from our series now.


Testing status: I've built and run this on our testbed
machine,
including a rename test harness, but it hasn't been run on
production machines yet.


Bron.

Simon Matter wrote:
>> I am pleased to announce the release of Cyrus IMAPd
2.3.12.  This
>> release should be considered production quality.
>>
>>
>> Noteworthy changes:
>>
>> * Added statuscache.db to cache IMAP STATUS data
which
>> significantly reduces the amount of I/O necessary
when neither the
>> mailbox nor Seen state has changed -- courtesy of
Fastmail.fm
> 
> While upgrading my RPM packages I found that logging is
too noisy for my
> taste. I get alot of syslog messages like so:
> 
> Apr 24 11:35:30 test imap[10457]: statuscache,
'user.simix', 'simix',
> '0x13', 'yes'

These messages are at the DEBUG level.  Do you usually ship
your RPM 
with the logging set to DEBUG?  I don't really see a problem
leaving 
these messages alone, since I would expect most production
systems to be 
logging at INFO or higher.


-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Simon Matter wrote:
>> Simon Matter wrote:
>>>> I am pleased to announce the release of
Cyrus IMAPd 2.3.12.  This
>>>> release should be considered production
quality.
>>>>
>>>>
>>>> Noteworthy changes:
>>>>
>>>> * Added statuscache.db to cache IMAP STATUS
data which
>>>> significantly reduces the amount of I/O
necessary when neither the
>>>> mailbox nor Seen state has changed --
courtesy of Fastmail.fm
>>> While upgrading my RPM packages I found that
logging is too noisy for my
>>> taste. I get alot of syslog messages like so:
>>>
>>> Apr 24 11:35:30 test imap[10457]: statuscache,
'user.simix', 'simix',
>>> '0x13', 'yes'
>> These messages are at the DEBUG level.  Do you
usually ship your RPM
>> with the logging set to DEBUG?  I don't really see
a problem leaving
>> these messages alone, since I would expect most
production systems to be
>> logging at INFO or higher.
> 
> The RPM logs to mail facility and priority of mail is *
by default on
> RedHat. That means out of the box we get quite alot
messsages in maillog
> now. With statuscache enabled the number of log entries
is about 10 times
> higher than without.
> I understand that others may want those logs at the
DEBUG level, it's only
> a problem in my situation.


Don't you also get a ton of transaction log messages,
regardless of the 
statuscache code?

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University