Re: [Evolution-hackers] imapx last-minute fix for 3.0?
On Sun, 2011-03-20 at 16:39 -0400, Matthew Barnes wrote: > David assured me the patches are low risk, so I recommended he try for > 3.0 even though it's last minute, since new translatable strings are a > tougher sell in stable updates. Just to follow up, we wound up deferring this to 3.1 for a number of reasons: 1) This is a workaround for a broken IMAP server, not a bug in imapx. 2) Due to limitations in CamelProviderConfEntry, David had to word the option in reverse of what would be most natural and understandable. [I expect to be changing Camel's configuration framework as part of my account-mgmt project for 3.2, though I'm not sure exactly how it will change yet. I'll keep this in mind as a use case.] 3) We got push back from the release team, mostly over (2), and decided it's not worth a last-minute fight since we too are unhappy with the wording of the option. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] imapx last-minute fix for 3.0?
On Sun, 2011-03-20 at 13:37 +, David Woodhouse wrote: > This means new strings, which it's already late for, and it means code > changes, which it's damn close for since I haven't actually written them > yet. But still I suspect it's a good idea to get these into 3.0 since we > really want to be able to laugh and point at anyone who is still using > the old IMAP back end in 3.0. It should be deprecated, and IMAP+ should > be the default (is it?). David and I talked it over on IRC today, so this is just for the record since no one else was around. David assured me the patches are low risk, so I recommended he try for 3.0 even though it's last minute, since new translatable strings are a tougher sell in stable updates. We'll need to beg the release team for a string and possibly code freeze break (code freeze for 3.0 is Monday at 23:59 UTC). It helps if we can point the release team to a bug with patches so they can read it over and make a more informed risk assessment. David said he's on it. I also had him go ahead an remove the ESoapMessage and ESoapResponse APIs so they can be reworked. A soname bump in libedataserver would be tremendously disruptive right now, and I think the odds of anyone else using these new APIs already is slim enough that we can get away with just silently yanking them. GLib pulled the same stunt recently with the GApplication API, so there's precedent. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] imapx last-minute fix for 3.0?
I've been working with Thomas to diagnose an imapx problem which turns out to be a Domino IMAP server bug. When we fetch a message chunk, the Domino server will lie to us about the size of a literal that it's about to send us. It tells us a larger size than it actually sends, so we 'eat' its command completion as if it were part of the message chunk, then wait for ever for the end of the literal data and the subsequent completion that's never coming. My plan for fixing this is: - A configuration option for disabling multi-part fetch. - Ensure we have a sane timeout on incoming messages, so we time out in a reasonable amount of time in the above situation rather than hanging for ever. - When we *do* time out, look at the last line of the buffer that we *did* receive, to see if it looks like a command completion. If it does, then pop up an error message which advises the user to try disabling the multi-part fetches. Or better still, just *do* it. This means new strings, which it's already late for, and it means code changes, which it's damn close for since I haven't actually written them yet. But still I suspect it's a good idea to get these into 3.0 since we really want to be able to laugh and point at anyone who is still using the old IMAP back end in 3.0. It should be deprecated, and IMAP+ should be the default (is it?). Thoughts? -- dwmw2 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
