Things for 2.3.13

[Wesley Craig]

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:
>>     https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3075
>> 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  
problem.

>> . proxies quota commands when supports_referrals is 0.

Toss up.

>> . 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  
generate.

>> 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.

:wes