Jack Bailey wrote:
Cedric Puddy wrote:
My experience is that the daemon performs much better than "alpha" would ordinarily indicate.
Absolutely true.
and there's the nomenclature itself. "Alpha" means (or at least it used to mean) testing under control of the developers. "Beta" means testing under control of the users. It looks like we all agree that Dovecot is beyond both.
Well sorta ... In my experience with s/w development, I have used the alpha designation to mean that the code was fairly stable and usable, but not necessarily feature complete. Alpha code is only made available to selected and highly skilled users who can provide detailed bug reports including a test case that exposes the bug.
Beta code is deemed feature complete and ready for wider testing. Beta code should not need any great thrashing of internals to be ready for release, however if needed, do it. Beta s/w should also include at least a completed first-draft of the user documentation.
After an appropriate period of beta-testing and a final draft of the user documentation, a series of release candidates is started. When an appropriate time period has passed w/o any patches, the s/w is formally released.
On more occasions that I like to admit, I have been forced by scheduling requirements from senior management to fudge the above rules a bit. C'est guerre.
In the case of Dovecot, there seems to be aspects of the project that fit all of the above coding stages.
My (unsolicited) advice to Timo would be to create a branch tag to the project as soon as practical and apply the bug fixes to the branch as needed, as well as to HEAD. Feature development can continue on HEAD as planned. These new features would appear in later releases such as 1.(n+1), etc...
As soon as the bug rate to the branch tapers off, create the 1.0 release tarball from the branch tag. This method is roughly the same as the OpenBSD development team uses and it clearly works rather well. Nobody, in my experience, produces a tighter and cleaner software product than OpenBSD in both the free or commercial world.
The key here is to create a branch that will only have bug fixes applied which is separate from on-going development. A significant portion of the instability seen in Dovecot is to the continuing development. These two activities need to be separated to achieve the desired stability in the released code.
I have been using Dovecot for the last 3 years and have rarely had any trouble with it even though it has been been labeled -test and -alpha. My thanks to Timo and his merry elves for a filling need in the open source community. IMHO, Dovecot is already best-of-breed.
It is testimony to the competence of Timo and crew that Dovecot is rather stable. Separating bug-fixing from feature development can make Dovecot uncommonly so.
Just my $0.02 Ray
PS Long diatribes happen when one has free time on a cold rainy Saturday night.