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
