[Dovecot] Dovecot software testing and release practice

[Andreas Kasenides]

Since this, it seems, was lost in, the now infamous, 2.2.9 thread I 
would like to resubmit the following proposal for Timo's consideration. 
Thanks Timo for doing an excellent job. I believe that the following 
will add further value to Dovecot in the long run.

Thankx
Andreas
============================

> On 23-11-2013 3:47, Noel Butler wrote:
> 
>    On Fri, 2013-11-22 at 10:14 +0100, Ralf Hildebrandt wrote:
>        * Thomas Leuxner <tlx at leuxner.net>:
>            * Ralf Hildebrandt <Ralf.Hildebrandt at charite.de> 2013.11.22 
> 09:44:
> 
>                Which patch?
> 
>            
> http://www.dovecot.org/list/dovecot/2013-November/093654.html 
> Pigeonhole related patches.
>        Damn. Those are biting me as well :/
> 
> These would be found if Timo reverted back to issuing RC's before any 
> official release, to iron out the
> niggly off-putting bugs, like most software does, or gets his devs and 
> a community of official > >testers>each with wildly different 
> configurations and set ups, ASF have an excellent model that could be 
> >followed, >bunch of devs and testers who each report on different distros and configs, why? because no >single dev can imagine and test every possible configuration. it might just save dovecot's good name, I >recall a lot of damage was done to that in the circles I'm in when 2.0 was released with patches nearly >every few days and weeks, I know a few ISP's and businesses that went back to courier or Wu's because >major bugs were getting in often, though it has been a lot better since 2.1 series, until this release >that is :)


I second this and offer my services for two, three different system 
configs from  Dovecot's plain old simple config with MAILDIR to slightly 
more complicated configurations with proxying/LDAP/dsync/mySQL etc based 
on virtualization with KVM.

I also propose that upon employing above strategy that Timo should come 
up with a release cycles (long term, short term) with announced targets. 
Patches should be released as patches strictly as needed, not releases, 
and should be announced on a low traffic list like he is already doing 
with releases. OR something along these lines.

I know these are growing pains but essential. Email systems are CRITICAL 
for most of us.

Andreas