[Dovecot] v1.1.10 released
http://dovecot.org/releases/1.1/dovecot-1.1.10.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.10.tar.gz.sig
v1.1.9 wasn't such a great release. Once again: Would be great if someone started a proper testing suite so releases could be tested..
- Maildir: Keyword handling was somewhat broken in v1.1.9
- userdb prefetch was broken with blocking passdbs in v1.1.9
- dict process didn't always die with the rest of Dovecot
- dict quota was somewhat broken with pgsqlTimo Sirainen schrieb:
http://dovecot.org/releases/1.1/dovecot-1.1.10.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.10.tar.gz.sig
v1.1.9 wasn't such a great release. Once again: Would be great if someone started a proper testing suite so releases could be tested..
what you mean with testing suite exactly ? some code stuff or a bunch of different testing servers in i.e vmware etc?
- Maildir: Keyword handling was somewhat broken in v1.1.9
- userdb prefetch was broken with blocking passdbs in v1.1.9
- dict process didn't always die with the rest of Dovecot
- dict quota was somewhat broken with pgsql
-- Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
On Jan 26, 2009, at 7:49 PM, Robert Schetterer wrote:
Timo Sirainen schrieb:
v1.1.9 wasn't such a great release. Once again: Would be great if someone started a proper testing suite so releases could be tested..
what you mean with testing suite exactly ? some code stuff or a bunch of different testing servers in i.e
vmware etc?
Something automated. There are several different testing possibilities
actually. Unit tests is one thing. Another would be something which
actually started Dovecot using different configurations and then ran
my imaptest tool against all the configurations. Whenever a bug is
found in some specific configuration, a test will be added that
catches it if it happens again. So I guess that would be regression
testing.
Quoting Timo Sirainen <tss@iki.fi>:
Something automated. There are several different testing
possibilities actually. Unit tests is one thing.
Last time I brought this up, it lead to so much endless arguing/debate over what type of testing to use, what toolset to use, etc. that nothing ever happened.
I'd still be willing to do unit tests, if there is no longer any arguments from others to stop it. I'm open to suggestions as to tools to use and such as long as it isn't a flame war...
Arguing about how to do things usually leads to nothing getting done, which is what happened here...
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
On Tue, 2009-01-27 at 11:21 -0600, Eric Rostetter wrote:
Quoting Timo Sirainen <tss@iki.fi>:
Something automated. There are several different testing
possibilities actually. Unit tests is one thing.Last time I brought this up, it lead to so much endless arguing/debate over what type of testing to use, what toolset to use, etc. that nothing ever happened.
Why don't I remember the arguing? :) Maybe I was just following to see what's going to be the result and it eventually died out and I thought people just lost interest.
I'd still be willing to do unit tests, if there is no longer any arguments from others to stop it. I'm open to suggestions as to tools to use and such as long as it isn't a flame war...
I've already written some unit tests in src/tests/. I don't really care if you continue them the way I started or use some other toolset. And unless someone else is also willing to actually write the tests, I don't think you should care all that much about their arguing.
As someone once pointed out to me when I was on a jihad for error-checking/returning in a code development project, it's the things that you *know* might break that you can slow down your code by putting RC evals (evals are always very, very slow) to report on, but you generally check for them *anyway* in your testing process...so why put them in?....it's the stuff that you never thought of (and couldn't put RC checking in for) that will break and bite you in the ass and leave you wondering WTF is going on
Timo Sirainen wrote:
On Tue, 2009-01-27 at 11:21 -0600, Eric Rostetter wrote:
Quoting Timo Sirainen <tss@iki.fi>:
Something automated. There are several different testing
possibilities actually. Unit tests is one thing.Last time I brought this up, it lead to so much endless arguing/debate over what type of testing to use, what toolset to use, etc. that nothing ever happened.
Why don't I remember the arguing? :) Maybe I was just following to see what's going to be the result and it eventually died out and I thought people just lost interest.
I'd still be willing to do unit tests, if there is no longer any arguments from others to stop it. I'm open to suggestions as to tools to use and such as long as it isn't a flame war...
I've already written some unit tests in src/tests/. I don't really care if you continue them the way I started or use some other toolset. And unless someone else is also willing to actually write the tests, I don't think you should care all that much about their arguing.
-- ==== Once upon a time, the Internet was a friendly, neighbors-helping-neighbors small town, and no one locked their doors. Now it's like an apartment in Bed-Stuy: you need three heavy duty pick-proof locks, one of those braces that goes from the lock to the floor, and bars on the windows.... ==== Stewart Dean, Unix System Admin, Bard College, New York 12504 sdean@bard.edu voice: 845-758-7475, fax: 845-758-7035
Quoting Timo Sirainen <tss@iki.fi>:
I've already written some unit tests in src/tests/. I don't really care if you continue them the way I started or use some other toolset. And
What branch(es) should I write them for (1.0, 1.1, and/or 1.2). If multiple branches, which is most important?
unless someone else is also willing to actually write the tests, I don't think you should care all that much about their arguing.
How to submit them (mercurial access, patches to you or the list, or some other way).
I check out the mercurial repos and see what is there, and see what I can do...
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
On Tue, 2009-01-27 at 14:20 -0600, Eric Rostetter wrote:
Quoting Timo Sirainen <tss@iki.fi>:
I've already written some unit tests in src/tests/. I don't really care if you continue them the way I started or use some other toolset. And
What branch(es) should I write them for (1.0, 1.1, and/or 1.2). If multiple branches, which is most important?
v1.2, since that's where all the new code goes. I guess they could be backported to v1.1 also but I don't see it as important. I'm hoping for a soonish v1.2.0 release and after that v1.1 won't have as much changes anymore.
unless someone else is also willing to actually write the tests, I don't think you should care all that much about their arguing.
How to submit them (mercurial access, patches to you or the list, or some other way).
hg export patches or hg bundles would be best I think. I'm not sure if they should go to list or not. Depends on if anyone else wants to see them, but since there's already dovecot-cvs list I'm guessing private mails to me would be ok.. Or perhaps the first few could be sent to this list in case someone has suggestions how something could be done better.
Timo Sirainen wrote:
On Tue, 2009-01-27 at 14:20 -0600, Eric Rostetter wrote:
Quoting Timo Sirainen <tss@iki.fi>:
I've already written some unit tests in src/tests/. I don't really care if you continue them the way I started or use some other toolset. And
What branch(es) should I write them for (1.0, 1.1, and/or 1.2). If multiple branches, which is most important?
v1.2, since that's where all the new code goes. I guess they could be backported to v1.1 also but I don't see it as important. I'm hoping for a soonish v1.2.0 release and after that v1.1 won't have as much changes anymore.
is there any ETA for dovecot 1.2 beta, rc, final?
What ideas do people have on a good going forward framework/matrix?
Caltech, which largely translate to myself, will be going through a validation process before we upgrade. After reading the dovecot and some other wikis, I realize I can do better. It would be nice to be more general.
We are upgrading precisely because of race conditions. My latest joy, two stratum one clocks that are 1s apart.
Our server environment is pretty specific but there is a lot of diversity in our user base. The outliers are good test cases.
---Jack
Timo Sirainen wrote:
http://dovecot.org/releases/1.1/dovecot-1.1.10.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.10.tar.gz.sig
v1.1.9 wasn't such a great release.
I refreshed the ManageSieve patch for v1.1:
http://www.rename-it.nl/dovecot/1.1/dovecot-1.1.10-managesieve-0.10.5.diff.g... http://www.rename-it.nl/dovecot/1.1/dovecot-1.1.10-managesieve-0.10.5.diff.g...
Regards,
-- Stephan Bosch stephan@rename-it.nl
On Jan 26, 2009, at 6:32 PM, Timo Sirainen wrote:
http://dovecot.org/releases/1.1/dovecot-1.1.10.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.10.tar.gz.sig
Timo:
Did you get around to modifying deliver wherein the '-e' has become
default behavior... per the earlier discussion?
B. Boger
On Jan 26, 2009, at 10:36 PM, Bruce Bodger wrote:
On Jan 26, 2009, at 6:32 PM, Timo Sirainen wrote:
http://dovecot.org/releases/1.1/dovecot-1.1.10.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.10.tar.gz.sig
Timo:
Did you get around to modifying deliver wherein the '-e' has become
default behavior... per the earlier discussion?
Not yet, and it's not going to change for v1.1 in any case, only v1.2
maybe. I did start reconsidering it though since rejection_* settings
won't work after that.
Timo Sirainen wrote:
http://dovecot.org/releases/1.1/dovecot-1.1.10.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.10.tar.gz.sig
v1.1.9 wasn't such a great release. Once again: Would be great if someone started a proper testing suite so releases could be tested..
- Maildir: Keyword handling was somewhat broken in v1.1.9
- userdb prefetch was broken with blocking passdbs in v1.1.9
- dict process didn't always die with the rest of Dovecot
- dict quota was somewhat broken with pgsql
Version 1.1.10 fixed the problem I was seeing.
Thanks!
-- Love feeling your best ever, all day, every day? Click http://RadicalHealth.com/join for the easy way.
participants (9)
-
Bruce Bodger
-
David Favor
-
Eric Rostetter
-
Jack Stewart
-
Michal Hlavinka
-
Robert Schetterer
-
Stephan Bosch
-
Stewart Dean
-
Timo Sirainen