Things for 2.3.13
wes at umich.edu
Thu Sep 25 11:46:41 EDT 2008
On 25 Sep 2008, at 11:35, Ken Murchison wrote:
> Wesley Craig wrote:
>> On 23 Sep 2008, at 22:43, Bron Gondwana wrote:
>>> That's my entire wishlist for 2.3.13 (plus the buffer size patch you
>>> already included)
>> I think there should be an RC2.
>> I don't see:
>> included in RC1. I gathered that *was* on your wishlist for 2.3.13.
> Isn't this the fix that Bron said needs more discussion? Or am I
> confusing it with something else.
No, the "more discussion" part was stacked transactions. Which seems
simple enough, but I'm not really prepared to evaluate the overall idea.
>> I've marked a few other bugzilla items as blockers, as an
>> indication of what I think should go into 2.3.13. In general,
>> unified murder continues to be broken for many uses. I have fixes
>> for 2914, but 2915 requires some discussion. There's also 2814,
>> 2973, and 2976, all related to unified murder faults.
> Unified Murder may have been a bad idea. I'm all for removing the
> code, unless folks find it useful and want it fixed.
I think it's a good idea. In particular, I think it's step in the
right direction for small installations. Wouldn't it be nice if you
could run a full murder with replication (and automatic failover, but
we're a long way from that) on a pair of machines?
>> . backend_connect edits prot->banner.is_capa.
> Depending where you're looking, it might be by design.
It causes crashes in some configurations.
> Are the bugs below blockers, or can they wait?
>> . the mupdate master reports changes to mupdate slaves out of
>> order if the change rate is higher that 1 every 10 seconds.
This is a blocker, I think. It likely the cause of certain
corruption on frontend.
>> . master starts two threads for every connection.
>> . mupdate slave ignores errors when writing NOOPs (e.g., that the
>> GSSAPI context has expired). There's also the possibility to get
>> our of sync with the mupdate master.
These two could wait.
>> . which implements the various LDAP changes that I've discussed on
>> the list.
I guess this could wait.
>> . adds debugging for ctl_mboxlist, replacing the assert I added
>> recently for cases where ctl_mboxlist was incorrectly removing
>> local mailboxes.
This should be included, in hopes of gathering sufficient data to
find whatever the bug is in mupdate master which causes the ordering
>> . proxies quota commands when supports_referrals is 0.
>> . which looks for cases of MODSEQ being inappropriately set to 0
>> and correcting it to be 1. Several buggy versions were released
>> into the wild, so it's quite likely that there are MODSEQ 0
>> mailboxes out there. Xfer-ing them to a machine with this code in
>> place will correct the corruption. Xfer-ing them to a machine
>> without this code in place causes sync_client to die.
This could be a blocker, given the support traffic it's likely to
>> I'm also pretty confident there's a bug in prot_select() which
>> causes it to return prematurely, indicating there's IO available
>> on a socket when instead there's just an event that needs to be
>> serviced. I haven't worked on a fix, but I think it's likely
>> there are deadlocks that happen as a result of this bug. Not that
>> I've seen any in the wild, yet.
Probably this should wait.
>> There might also need to be something done about the sieve utf-7
>> thing. Not that I have a proposal...
I'd probably ask the people who are complaining about it. They seem
pretty aghast at the change.
More information about the Cyrus-devel