Zimbra Quality Issues

[padraig]

I have used zimbra for some time now and find it reliable/stable and well featured.

However I have noticed new bugs with each minor release (which fixes old bugs).

Zimbra QA will verify a fixed bug but only after it has been reported, so the customer is effectually testing the software on production systems.

The is is acceptable for OOS, but i feel the NE release should lag behind the bleeding edge release e.g Fedora/Redhat EL also the NE should be fully pre-tested (INCLUDING THE ADMIN CONSOLE) on selected voluntary production servers with a large volume of users and e-mails.

This is NOT a rant but an attempt to improve an excellent system

[Klug]

I don't really see how you can "beta test" on "large infrastructure" (lots of users and email).

Unless you don't care about what can happen to your infrastructure because of the tests...

[padraig]

its simple zimbra or other can setup a test server which experienced users subscribe to (knowing it is test). This server is patched with thes latest releases first, testers then report issues to bugz.

This is what happens on my system i create a vmware(small infrastructure) i test as best i can report the NEW bugz and wait for the next fix

[Jbrabander]

But no one will have the same setup as the "official" Zimbra test server. There are numerous flavors of Linux, assorted patch levels, differing applications installed, etc. A test may work great if you test on the Zimbra test server, but it might then crash out on your own system.

Besides, every release of every software ever written contains bugs. Patches are put out, bugs are fixed, and new ones crop up. Such is the cycle of software production. Are the bugs a pain in the butt? Sure! But if you never install anything because you're waiting for the next patch, what good is the software?

[Protack]

Look at Microsoft. There OS has been in beta now for what, 18 years or so..

God Bless,
Marty

[dijichi2]

Call me a cynic, but every new release now I wait at least a couple of weeks and gauge response on the forums before installing it in production systems - such have been the range of problems with minor point releases.

I install OSS version on personal systems ASAP to help test new releases when I can.

I do like the idea of making the OSS version 'newer' than NE version, essentially making it a 'Fedora' to NE 'RHEL', therefore getting a lot of eyes on the code through OSS use before it hits paid NE systems. Makes a lot of sense from all sides.

[Klug]

110% agree with dijichi2 (and same behaviour about upgrading OSE and NE).

[nrc]

I agree. We watch for bug reports prior to upgrading and we've ended up passing on the previous two releases - we're still gauging response on 5.0.11. Our users are still in the "acceptance" phase and we can't afford to add new bugs.

I'd suggest making every other release purely a bug fix release targeting any significant new bugs that cropped up in the previous release. So even releases would include enhancements but the following odd release would be purely bug fixes. Odd releases could be OSS only if that would help speed the turn-around to a bug fix follow-up.

[Jbrabander]

I try to also watch the forums before doing an upgrade. I've had no issues with the 5.0.11 though. And we were pretty eager for the Outlook junk mail fix.

I do know, however, that I don't plan on putting in version 6 right away when it comes out. I'm fairly wary of anything with an x.0 version number.

[langs]

I do the same thing, infact I skipped 5.0.10 and went from 9->11. But doesn't the fact that we all wait and see how it goes before we do the upgrade say there is a problem with the release mechanism? at least for NE?

NE should be a highly polished and tested release, we shouldn't have to fear what it may introduce.