[Dovecot] Is it 1.0 yet?
OK - my last main bug was fixed a few releases ago. I know that there's no end to getting things right but there comes a point when you need to call it done. No one trusts a 1.0 to be perfect but Dovecot is already better that most 2.0 versions of other software.
I vote (as if my vote counted) to call it done, declare victory, and move on to 1.01, 1.02 etc. No one is going to trus it till it gets to 1.02 so I say lets bless it and move on.
<quote who="Marc Perkel"> > OK - my last main bug was fixed a few releases ago. I know that there's > no end to getting things right but there comes a point when you need to > call it done. No one trusts a 1.0 to be perfect but Dovecot is already > better that most 2.0 versions of other software. > > I vote (as if my vote counted) to call it done, declare victory, and > move on to 1.01, 1.02 etc. No one is going to trus it till it gets to > 1.02 so I say lets bless it and move on. > >
+1
-- Kind Regards,
Gavin Henry. Managing Director.
T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry@suretecsystems.com
Open Source. Open Solutions(tm).
Gavin Henry wrote:
<quote who="Marc Perkel">
OK - my last main bug was fixed a few releases ago. I know that there's no end to getting things right but there comes a point when you need to call it done. No one trusts a 1.0 to be perfect but Dovecot is already better that most 2.0 versions of other software.
I vote (as if my vote counted) to call it done, declare victory, and move on to 1.01, 1.02 etc. No one is going to trus it till it gets to 1.02 so I say lets bless it and move on.
+1
+2
On Wed 14 Feb 2007 at 02:14PM, Peter Fern wrote:
Gavin Henry wrote:
<quote who="Marc Perkel">
OK - my last main bug was fixed a few releases ago. I know that there's no end to getting things right but there comes a point when you need to call it done. No one trusts a 1.0 to be perfect but Dovecot is already better that most 2.0 versions of other software.
I vote (as if my vote counted) to call it done, declare victory, and move on to 1.01, 1.02 etc. No one is going to trus it till it gets to 1.02 so I say lets bless it and move on.
I agree except for my aformentioned concerns: if 1.0.1 is a bugfix release for 1.0, great. But I'd not like 1.0.1 to be chock full of new features which could introduce instability.
I'd like to see a risk managed, bug-fix-only 1.0.x train and a less stable 1.1 or 2.x train.
-dp-- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp
Dan Price wrote:
I agree except for my aformentioned concerns: if 1.0.1 is a bugfix release for 1.0, great. But I'd not like 1.0.1 to be chock full of new features which could introduce instability.
I'd like to see a risk managed, bug-fix-only 1.0.x train and a less stable 1.1 or 2.x train.
I concur with Dan, 1.0.x bugfix + 1.1 devel. Stability is more key to us rather than new features - if it wasn't for the namespace needs I'd probably be using 0.99 as that's what's in the RHEL release.
But I also concur with Marc, let's lock it down and ship it if we're pretty darn bug free. :) My beta testers love it, it's night and day compared to Courier re: performance. They don't know what 'Dovecot' is, but they know it rocks.
-te
-- Troy Engel | Systems Engineer Fluid Inc. | http://www.fluid.com
I concur with Dan, 1.0.x bugfix + 1.1 devel.
+1
But I also concur with Marc, let's lock it down and ship it if we're pretty darn bug free. :) My beta testers love it, it's night and day compared to Courier re: performance. They don't know what 'Dovecot' is, but they know it rocks.
Thats really good to know and what I am hoping for - as soon as 1.0 is released and is in portage, I'll be migrating our courier-imap over to dovecot. My test server seems pretty snappy, but there's a big difference between a test server and a production one... ;)
--
Best regards,
Charles
Hi Charles Marcus,
+1
I have wait for a long time :) ....
Charles Marcus wrote:
I concur with Dan, 1.0.x bugfix + 1.1 devel.
+1
But I also concur with Marc, let's lock it down and ship it if we're pretty darn bug free. :) My beta testers love it, it's night and day compared to Courier re: performance. They don't know what 'Dovecot' is, but they know it rocks.
Thats really good to know and what I am hoping for - as soon as 1.0 is released and is in portage, I'll be migrating our courier-imap over to dovecot. My test server seems pretty snappy, but there's a big difference between a test server and a production one... ;)
--
Best regards,
Charles
-- Xueron Nee xueron@gmail.com
Charles Marcus wrote:
Thats really good to know and what I am hoping for - as soon as 1.0 is released and is in portage, I'll be migrating our courier-imap over to dovecot. My test server seems pretty snappy, but there's a big difference between a test server and a production one... ;)
Agreed -- I just ran a non-scientific test for you, as I was curious myself.
Server A: SquirrelMail 1.4.5, Courier-IMAP 3.0.8, NIS+ lookups and NFS mounts to /home, Maildir (existing production, rock solid)
Time to open my mailbox: 36 seconds (*)
Server B: SquirrelMail 1.4.9 (in Courier config), Dovecot 1.0rc22 (Courier namespace mode), PAM/nss_ldap lookups with same NFS mounts (new beta server)
Time to open my mailbox: 4 seconds
Obviously there's a million factors (distro release, CPUs, memory, load, etc.) but across the board my beta users see astounding performance gains. Doing searches inside Thunderbird on random strings exhibits the same behaviour, what used to take a minute takes 2-3 seconds now.
-te
(*) about 7-8 years worth of mail
-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com
Agreed -- I just ran a non-scientific test for you, as I was curious myself.
Server A: SquirrelMail 1.4.5, Courier-IMAP 3.0.8, NIS+ lookups and NFS mounts to /home, Maildir (existing production, rock solid)
Time to open my mailbox: 36 seconds (*)
Server B: SquirrelMail 1.4.9 (in Courier config), Dovecot 1.0rc22 (Courier namespace mode), PAM/nss_ldap lookups with same NFS mounts (new beta server)
Time to open my mailbox: 4 seconds
wow...
Obviously there's a million factors (distro release, CPUs, memory, load, etc.) but across the board my beta users see astounding performance gains. Doing searches inside Thunderbird on random strings exhibits the same behaviour, what used to take a minute takes 2-3 seconds now.
Stop it! I was up all last night getting my server ready (upgraded to gcc 4.1.1 from 3.4.6, which, of course, meant I had to rebuild the entire box, which only took about 7 hours)...
<sigh>
Now I'm gonna have to find the time to just go ahead and do the migration... we experience the same slowness (courier-imap 4.0.4/maildir) with both squirelmail and tbird, to the point that searching on large folders (1+GB w/ 7k+messages) often will just timeout...
I think I'm actually salivating... lol
--
Best regards,
Charles
On 15.2.2007, at 0.21, Charles Marcus wrote:
Obviously there's a million factors (distro release, CPUs, memory,
load, etc.) but across the board my beta users see astounding
performance gains. Doing searches inside Thunderbird on random
strings exhibits the same behaviour, what used to take a minute
takes 2-3 seconds now. .. Now I'm gonna have to find the time to just go ahead and do the
migration... we experience the same slowness (courier-imap 4.0.4/ maildir) with both squirelmail and tbird, to the point that
searching on large folders (1+GB w/ 7k+messages) often will just
timeout...
Message body searches shouldn't be all that much faster with Dovecot
though. Actually I wouldn't even be surprised if they were somewhat
slower. I know Dovecot uses 3x more CPU time to perform the searches
than UW-IMAP, so there is a lot of room for improvement.
With message header searches it's faster though, because the headers
are stored in cache files.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Troy Engel wrote:
Dan Price wrote:
I agree except for my aformentioned concerns: if 1.0.1 is a bugfix release for 1.0, great. But I'd not like 1.0.1 to be chock full of new features which could introduce instability.
I'd like to see a risk managed, bug-fix-only 1.0.x train and a less stable 1.1 or 2.x train.
I concur with Dan, 1.0.x bugfix + 1.1 devel. Stability is more key to us rather than new features - if it wasn't for the namespace needs I'd probably be using 0.99 as that's what's in the RHEL release.
I would add: Once 1.0.x is released, and new development is occuring in 1.1.x (or whatever), *please* continue to support 1.0.x for bugfixes.
The current situation is that all but the very very latest distros ship 0.99.x, and nobody can get any support for this because 1.0rc* is around. This is a very bad situation, because the whole point of using a distro that contains the app you want is so that you don't have to build custom versions from source, or install RPMs/whatever from a source outside your distro. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF0zX3hk3bo0lNTrURAgayAJ9SvEJV7HhAvgKwvmz6os3Fb9qTpwCgsvQR DK2FUzfr8bObegIKrRBjXe0= =XvnB -----END PGP SIGNATURE-----
On Feb 13, 2007, at 12:46 PM, Marc Perkel wrote:
OK - my last main bug was fixed a few releases ago. I know that
there's no end to getting things right but there comes a point when
you need to call it done. No one trusts a 1.0 to be perfect but
Dovecot is already better that most 2.0 versions of other software.I vote (as if my vote counted) to call it done, declare victory,
and move on to 1.01, 1.02 etc. No one is going to trus it till it
gets to 1.02 so I say lets bless it and move on.
Agreed.
On Tue, Feb 13, 2007 at 12:46:19PM -0800, Marc Perkel wrote:
OK - my last main bug was fixed a few releases ago. I know that there's no end to getting things right but there comes a point when you need to call it done. No one trusts a 1.0 to be perfect but Dovecot is already better that most 2.0 versions of other software.
I only wish that dovecot would be able to use LDAP with reconnecting/rebinding before each authentication request: as I've mailed before, this is an issue for us, other softwares seems to work (because they reconnects each time, like ldap auth of squid for example). Ok, this may be a bug of OpenLDAP, I know ...
--
- Gábor
On Wed, 2007-02-14 at 09:44 +0100, Gábor Lénárt wrote:
I only wish that dovecot would be able to use LDAP with reconnecting/rebinding before each authentication request: as I've mailed before, this is an issue for us, other softwares seems to work (because they reconnects each time, like ldap auth of squid for example). Ok, this may be a bug of OpenLDAP, I know ...
Have you tried it since rc18? I thought it worked properly now.
On Wed, Feb 14, 2007 at 11:21:39AM +0200, Timo Sirainen wrote:
On Wed, 2007-02-14 at 09:44 +0100, Gábor Lénárt wrote:
I only wish that dovecot would be able to use LDAP with reconnecting/rebinding before each authentication request: as I've mailed before, this is an issue for us, other softwares seems to work (because they reconnects each time, like ldap auth of squid for example). Ok, this may be a bug of OpenLDAP, I know ...
Have you tried it since rc18? I thought it worked properly now.
Errr, well, sorry :) I've missed this point. I'm testing rc22 now with my own stretch tester, no fault got till now, which seems to be good (versions I had got problem with were at fault after some seconds of intensive stretch testing). Sorry for the noise :) If I have some fault I would post. Thanks!
--
- Gábor
I agree with most of your email, but maybe asking for a 1.0 release or pushing Timo to release it, is not that healthy.
The "when will be 1.0 released?" topic have been posted many times, and the common answer seems to be: "the rc works just fine but please let Timo decide when 1.0 will come out"
If you need a proof that the rc is working fine, just point your boss to the release notes of RedHat Enterprise 5, it has rc7 on it ;)
HTH Oliver
Marc Perkel wrote:
OK - my last main bug was fixed a few releases ago. I know that there's no end to getting things right but there comes a point when you need to call it done. No one trusts a 1.0 to be perfect but Dovecot is already better that most 2.0 versions of other software.
I vote (as if my vote counted) to call it done, declare victory, and move on to 1.01, 1.02 etc. No one is going to trus it till it gets to 1.02 so I say lets bless it and move on.
-- Oliver Schulze L. | Get my e-mail after a captcha in: Asuncion - Paraguay | http://tinymailto.com/oliver
Marc Perkel schrieb:
OK - my last main bug was fixed a few releases ago. I know that there's no end to getting things right but there comes a point when you need to call it done. No one trusts a 1.0 to be perfect but Dovecot is already better that most 2.0 versions of other software.
I vote (as if my vote counted) to call it done, declare victory, and move on to 1.01, 1.02 etc. No one is going to trus it till it gets to 1.02 so I say lets bless it and move on.
I'd urge Timo to leave it at "-rc" until the bug discovery (reporting) rate has dropped considerably, until a stable set of documentation files is ready to ship and only then call it stable.
Looking at the recent fixes, I think calling even rc22 "1.0" would be premature.
There is a lot of things to do before it can become 1.0, not the least is snapshotting the Wiki and polishing (in whichever order) a decent set of documentation files. Deferring to the Wiki is definitely not the way a "stable" software should be shipping its documentation. What if the Wiki is down? Poking into the black... not a good idea.
There is absolutely no reason to rush 1.0 forward, because the label bears no significance whatsoever about quality, and even less is the code base as such impressed by such external "declaration of stability".
For those who want it, 1.0-rc* works well at many sites, and the openSUSE build service has current candidates for public download (of course, without warranties as to the usability or support, but they've been quick to pick up new rc's).
My recent message (a few minutes ago, check the message date) in the "resilience suggestion" thread has more points about this topic.
Best regards, Matthias Andree
On Wed, Feb 14, 2007 at 06:57:37PM +0100, Matthias Andree wrote:
Marc Perkel schrieb:
OK - my last main bug was fixed a few releases ago. I know that there's no end to getting things right but there comes a point when you need to call it done. No one trusts a 1.0 to be perfect but Dovecot is already better that most 2.0 versions of other software.
I vote (as if my vote counted) to call it done, declare victory, and move on to 1.01, 1.02 etc. No one is going to trus it till it gets to 1.02 so I say lets bless it and move on.
I'd urge Timo to leave it at "-rc" until the bug discovery (reporting) rate has dropped considerably, until a stable set of documentation files is ready to ship and only then call it stable.
I'd have to agree with this opinion. I am relatively new to Dovecot, but RC18 through RC21 had a large number of significant bugs, crashes and other problems.
Most of them, if not all, appear to have been fixed, but it's somewhat concerning how many major issues were found.
It would seem to me that a total freeze on new features would be prudent, followed by a settling period of at least a month or two before considering it release quality.
-- Dean Brooks dean@iglou.com
Matthias Andree wrote:
There is absolutely no reason to rush 1.0 forward, because the label bears no significance whatsoever about quality, and even less is the code base as such impressed by such external "declaration of stability".
Not that I'm in a hurry for this, but I'd argue that there might be a reason to rush 1.0, which would be to encourage more work on 1.1.
So, while most people seem to want 1.0 "so that they can run a stable version," I'd say that getting 1.0, counterintuitivly, will actually make the 1.0.x release tree less stable, because more effort would go into new features in 1.1.
Ethan Sommer UNIX Systems Administrator Gustavus Adolphus College
Ethan Sommer wrote:
Matthias Andree wrote:
There is absolutely no reason to rush 1.0 forward, because the label bears no significance whatsoever about quality, and even less is the code base as such impressed by such external "declaration of stability".
Not that I'm in a hurry for this, but I'd argue that there might be a reason to rush 1.0, which would be to encourage more work on 1.1. So, while most people seem to want 1.0 "so that they can run a stable version," I'd say that getting 1.0, counterintuitivly, will actually make the 1.0.x release tree less stable, because more effort would go into new features in 1.1.
I agree. There are people who are holding out for the 1.0 milestone and I think it's ready to bring them in. I think everyone here agrees that Dovecot is far ahead of where most software that is 1.0 is so it's just a matter of labeling. Timo is a perfectionist which is good but I think there's a marketing factor here too. I think not going to 1.0 is holding Dovecot back.
Marc Perkel schrieb:
I agree. There are people who are holding out for the 1.0 milestone and I think it's ready to bring them in. I think everyone here agrees that Dovecot is far ahead of where most software that is 1.0 is so it's just a matter of labeling. Timo is a perfectionist which is good but I think there's a marketing factor here too. I think not going to 1.0 is holding Dovecot back.
So the result will be a huge merging headache when all the remaining 1.0 bugfixes need to be forward ported. Particularly with inferior merging systems such as CVS, it's going to be a lot of maintenance overhead without guarantees of getting it right.
I might be a bit more optimistic with SVK, Git, Mercurial or such things, but that's not Dovecot's repository system.
If you're into headaches, jump the gun.
Else, I haven't seen a reason to rush 1.0 I'd consider reasonable or compelling.
Not that I'm making Timo's decisions though.
On Thu, 2007-02-15 at 19:14 +0100, Matthias Andree wrote:
So the result will be a huge merging headache when all the remaining 1.0 bugfixes need to be forward ported. Particularly with inferior merging systems such as CVS, it's going to be a lot of maintenance overhead without guarantees of getting it right.
Actually CVS HEAD and branch_1_0 has existed for almost a year already, and I've been committing all the fixes to both branches.. Yea, kind of annoying, but I still haven't figured out what I'd like to switch to from CVS :)
Matthias Andree wrote:
So the result will be a huge merging headache when all the remaining 1.0 bugfixes need to be forward ported. Particularly with inferior merging systems such as CVS, it's going to be a lot of maintenance overhead without guarantees of getting it right.
It doesn't have to be that way -- merging *is* a pain with CVS, I think we all agree. Instead what our guys do is keep two checked out branches of code, and any bugfix patches get committed to both branches (where appropriate) at the same time. It may seem like more work, but actually results in less errors and you never have to merge.
I colloquially refer to this as 'branch and forget' for any better explanation - no merge will ever happen.
-te
-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com
participants (15)
-
Andrew Moran
-
Charles Marcus
-
Dan Price
-
Dean Brooks
-
Ethan Sommer
-
Gavin Henry
-
Gábor Lénárt
-
Marc Perkel
-
Matthias Andree
-
Oliver Schulze L.
-
Peter Fern
-
Stephen Warren
-
Timo Sirainen
-
Troy Engel
-
Xueron Nee