On Fri, Jul 21, 2006, Paul J Stevens <[EMAIL PROTECTED]> said: > Aaron Stone wrote: >> On Fri, 2006-07-21 at 16:59 +0200, Paul J Stevens wrote: >>> I'm sorry Aaron, but I'm rejecting your patch. It starts breaking stuff >>> (sig11) all over the place, I don't have time to fix them all, and I >>> don't want to leave the tree in a non-functional state. I'm leaving the >>> country next week, and I would like to get 2.1.7 out before then. >> >> Bah, crap. I'll see about un-segfaulting in the next 24 hours.
Paul, I don't know what segfaults you're seeing, but I'm not seeing them. Please point me in the direction of the problems you're getting so that I can fix them! > Perhaps we should cut a branch for 2.2, and keep the untested changes in > trunk. > > That way, I can use branch_2_2 for releasing 2.1.7 as a final pre-2.2 > cut, and do 2.2.x from there. I don't want to kill the schedule, but I do want this code in 2.2. >>>> - Sieve support updated for libSieve 2.1.11. (sortsieve.c) >>> Is there still api compatiblity with 2.1.10? >> >> Keep this. I am not guaranteeing anything along the libSieve 2.1 series. > > You're saying I shouldn't use sieve-2.1.11 for the packages? libSieve 2.1.11 fixes a number of bugs in 2.1.10 and has better conformance to the newer RFC's and drafts. I haven't tested if the same Sieve code from DBMail 2.1.6 will work with libSieve 2.1.11; it should, I designed the API that way, but the bugfixes outweigh the usefulness of compatibility testing. Aaron
