[Dovecot] Dovecot software testing and release practice
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@leuxner.net: * Ralf Hildebrandt Ralf.Hildebrandt@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
participants (1)
-
Andreas Kasenides