Le 30.03.2007 18:23, Geert Hendrickx a écrit :

On Fri, Mar 30, 2007 at 05:47:30PM +0200, Robert Schetterer wrote:

...

HI Timo, you added the wiki in txt format to the docs dir, this again brokes my suse spec *g

What annoys me more (as dovecot maintainer for pkgsrc) is that the example config file changes with (almost) every release. The changes are mostly just in comments, but it makes users have to merge their configuration on every update.

Changes will be certainly minimal after v1.0 final release, you can't blame Timo for trying to make something more and more usable and adapted to everybody's needs while v1.0 is still in development..

-- Nico Rien ne m'est sûr que la chose incertaine. -+- François Villon (1431-1463?), Ballade du concours de Blois (vers 9) -+-

On Fri, 30 Mar 2007 14:02:09 -0700 Kenneth Porter shiva@sewingwitch.com wrote:

This is why I'm still using 0.99.

Which Timo describes as being so old as to be effectively a different program......

--

Brian Morrison

bdm at fenrir dot org dot uk

"Arguing with an engineer is like wrestling with a pig in the mud; after a while you realize you are muddy and the pig is enjoying it."

GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html

--On Friday, March 30, 2007 3:24 PM -0700 Frank Cusack fcusack@fcusack.com wrote:

...

This is why I'm still using 0.99. The RC's still look like betas and I have no idea which one (if any) is less a regression than any other.

They ARE betas. That's no reason to stay with 0.99. It's effectively beta as well.

In principle, a "release candidate" should be a gamma. It should be effectively ready for release, and distributed to check for awful show-stoppers.

Is 1.0rc29 stable enough to replace 0.99 from Fedora? Will I suddenly have a bunch of angry users seeing things break?

1.0.rc1 was released in June. Here's a quote from the release message for rc11 (November 4):

Hopefully the last RC release? As far as I know there are no major problems left now. If nothing big shows up, v1.0 should be out in a couple of weeks.

In rc27:

A few new small features and lots of index/mbox fixes. I've been heavily stress testing this release, so I think it should be about perfect. :)

*Features*?! In an rc?! No wonder there's no convergence.

If I were installing this for just me, I'd have no problem riding the bleeding edge and accepting the risk. But I don't want my boss showing up at my door livid because some last-minute feature caused a bad regression. When I install software for others to use, I want something that's been running in the field for awhile. I don't care if it has bugs, as long as I know what to expect. What I want is certainty, not perfection.

So please, no more features in these rc's! Just lock it down and ship it and let people get some experience with it, so I'll know exactly what to expect when *I* install it.

On March 30, 2007 7:31:15 PM -0400 Dean Brooks dean@iglou.com wrote:

On Fri, Mar 30, 2007 at 04:05:55PM -0700, Kenneth Porter wrote:

...

...

A few new small features and lots of index/mbox fixes. I've been heavily stress testing this release, so I think it should be about perfect. :)

*Features*?! In an rc?! No wonder there's no convergence.

[snip]

So please, no more features in these rc's! Just lock it down and ship it and let people get some experience with it, so I'll know exactly what to expect when *I* install it.

I have to agree with you on this. I'm relatively new with Dovecot and have been evaluating it for deployment in a production environment. I must say that Dovecot has the most unusual development method of a large-scale project I've seen.

???

1. write code
2. release for testing
3. incorporate feedback

Doesn't seem that unusual. It's just that "rc" is misnamed.

There have been so many show-stopping bugs in the past 10 releases that I wouldn't even consider this a candidate for a Beta release at this point, let alone a production release.

Sure, Timo probably did screw up by wanting 1.0 to be so great and all, and not just freezing things where they stood, but who cares? Just stick with 0.99 or 1.0beta8. It's great that he releases so many "rc" versions and so many people test them and shake out bugs.

I'm very appreciative of all the hard-work the author(s) have put into this, but I think at some point they need to take a hard-look at the way they develop and release distributions. It seems extremely sloppy and I know it's confusing to others besides myself.

It's very easy. In the dovecot world, "rc" means "development version". Or are you too stupid and ignorant to learn how the versioning works for dovecot. (Sorry, that's directed to another dovecot thread; I'm not calling you stupid and ignorant.)

Seriously though, if you so desperately want dovecot frozen somewhere, use 1.0beta8 or 1.0rc1 and pretend it was released as 1.0.

-frank

On March 30, 2007 5:04:58 PM -0700 Kenneth Porter shiva@sewingwitch.com wrote:

--On Friday, March 30, 2007 4:52 PM -0700 Frank Cusack fcusack@fcusack.com wrote:

...

It's very easy. In the dovecot world, "rc" means "development version". Or are you too stupid and ignorant to learn how the versioning works for dovecot. (Sorry, that's directed to another dovecot thread; I'm not calling you stupid and ignorant.)

That's fine for isolated users supporting only themselves. But it won't win any mind share in the boardroom. If you want widespread deployment to get proper testing (and hence a larger user base) you need a version number that gives business people the confidence to install it. Otherwise you'll be limited to avant garde hobbyists who have nothing to risk.

Once 1.0 locks down, you should see a huge expansion of users.

Please don't mistake my email for any involvement with dovecot development. AFAIK, Timo is the one and only developer. That's sure to win over your board and boards worldwide.

FWIW, in my experience, all 1.0 software is utter shit and should be avoided like the plague if stability is a requirement. So 0.99, 1.0, etc is all meaningless to me.

-frank

On Fri, 30 Mar 2007, Frank Cusack wrote:

FWIW, in my experience, all 1.0 software is utter shit and should be avoided like the plague if stability is a requirement. So 0.99, 1.0, etc is all meaningless to me.

1.0 = shit is almost always true for payware IMHO. Open source has a far better track record on this. If I had to give dovecot a version number right now, I would say it is about version 9.8.

My one concern about dovecot is the "feeping creaturism" in the code. Why does it have to be an LDA? That is what procmail is for. And designing your own mailbox format (dbox?) seems dangerous too. I would have it stick to POP and IMAP, period. But then it is not my code either. It works great for IMAP, which is what I need.

Jeff Earickson Colby College

--On Saturday, March 31, 2007 8:55 AM -0400 Gerard gerard@seibercom.net wrote:

Personally, I like the LDA feature in Dovecot. Procmail is a memory hog with a cavorted rules configuration scheme. Its use has seriously declined in favor of better products now available.

Procmail is best left to single user status. I would never consider employing it in a multi user environment, although I know it has been done. Why though I fail to understand. There are better and easier methods available.

I've been using procmail for a long time but I'm open to trying something else. A look at the wiki indicates that Dovecot uses a Sieve plugin to accomplish filtering.

http://wiki.dovecot.org/LDA/Sieve

What other "better and easier" methods are you referring to?

Are there any conversion tools for converting files of procmail rules to Sieve syntax?

The bulk of my rules look for the Mailman List-ID header and file to a mbox mailbox named after the list. For example, here's my Dovecot list rule:

:0 :

• ^List-ID:.*dovecot mail/Lists/Mail/Dovecot

On Sat, Mar 31, 2007 at 08:32:40AM -0400, Jeff A. Earickson wrote:

My one concern about dovecot is the "feeping creaturism" in the code. Why does it have to be an LDA? That is what procmail is for. And designing your own mailbox format (dbox?) seems dangerous too. I would have it stick to POP and IMAP, period. But then it is not my code either. It works great for IMAP, which is what I need.

Using the Dovecot LDA will improve POP3/IMAP performance, as the index files are being updated on delivery instead of login time. So it sure makes sense to combine the LDA with the POP3/IMAP daemon. An as soon as those are combined, the actual mailbox format (mbox/maildir/dbox) is just an internal interface for dovecot.

Geert

At 8:32 AM -0400 3/31/07, Jeff A. Earickson wrote:

On Fri, 30 Mar 2007, Frank Cusack wrote:

...

FWIW, in my experience, all 1.0 software is utter shit and should be avoided like the plague if stability is a requirement. So 0.99, 1.0, etc is all meaningless to me.

1.0 = shit is almost always true for payware IMHO. Open source has a far better track record on this. If I had to give dovecot a version number right now, I would say it is about version 9.8.

My one concern about dovecot is the "feeping creaturism" in the code. Why does it have to be an LDA? That is what procmail is for.

That specific case is a very good thing. Procmail is not a good piece of software to rely on and offer to users as their filtering tool.

-- Bill Cole
bill@scconsult.com

On 2007 Mar 30 (Fri) at 17:04:58 -0700 (-0700), Kenneth Porter wrote: :That's fine for isolated users supporting only themselves. But it won't win :any mind share in the boardroom. If you want widespread deployment to get :proper testing (and hence a larger user base) you need a version number :that gives business people the confidence to install it.

When did the boardroom understand mail servers? I must have missed that memo. I tell them it is a fully functional, sturdy, reliable and fast email server infrastructure that they don't have to worry about.
And since thats true, they don't have to worry about it.

This sort of decision is exactly why I'm the mail admin and they are not. They know things at the boardroom level, and they are (presumably) good at it. I don't look at things from the boardroom level. However, I understand the MTA-related arena better than they do. If they understood the details, why would they spend the money on my salary.

Would it make you feel better if Timo decided that the next rc level was to be renamed 5.4? How about Enterprise Edition? The version number means nothing.

:Otherwise you'll be limited to avant garde hobbyists who have nothing to :risk.

And I resent the implication that I have nothing to risk. I take deep pride in the fact that I treat my home systems exactly the same as I would a professional mail server contract. Stability, reliability and reachability are crucial. Being a hobbyist does not mean I do not care about the quality of my gear, just that I spend my own money on it. I frequently just want it to Just Work, and it does. When I feel like fiddling, I make copies of the appropriate binaries/configs and if I do not get things back in their proper form then the working copies are restored.

-- Not only is this incomprehensible, but the ink is ugly and the paper is from the wrong kind of tree. -- Professor W., EECS, George Washington University

On 2007 Mar 30 (Fri) at 20:56:43 -0700 (-0700), Kenneth Porter wrote: :--On Friday, March 30, 2007 8:26 PM -0700 Peter Hessler :phessler@theapt.org wrote: : :>This sort of decision is exactly why I'm the mail admin and they are :>not. They know things at the boardroom level, and they are :>(presumably) good at it. I don't look at things from the boardroom :>level. However, I understand the MTA-related arena better than they do. :>If they understood the details, why would they spend the money on my :>salary. : :So which rc are you running in production? What made you decide that rc and :not some other was "good enough" without being "too risky". What's your :confidence in that particular rc? : :I'm looking at 29 rc's and I have no idea how to pick. What's your method?

I personally am running rc22, and plan on upgrading to rc29 this weekend. I chose it because it was the most recent dovecot when I last upgraded. I've previously been upgrading to each rc within a day or two of release. My upgrade testing goes like this: Install it on a non-mailserver box, setup a bogus mail directory (usually a cp of my regular Maildir/), poke at it with ipv4/ipv6 over both imap and pop3.
Usually 20 minutes is enough to figure its quality. If it passes, then I kill the master dovecot process, uninstall old, install new, start up, run tests again.

-- Don't take life so serious, son, it ain't nohow permanent. -- Walt Kelly

Kenneth Porter wrote:

That's fine for isolated users supporting only themselves. But it won't win any mind share in the boardroom. If you want widespread deployment to get proper testing (and hence a larger user base) you need a version number that gives business people the confidence to install it. Otherwise you'll be limited to avant garde hobbyists who have nothing to risk.

Once 1.0 locks down, you should see a huge expansion of users. Bug fixes (not features!) in 1.0.1 will see further expansion. Any new features (like the recent addition of the wiki to the tarball) should be in the scary and experimental 1.1, not 1.0.

Three comments from a regular reader of this list:

• Dovecot has been safe to use in many configurations for quite a long time, certainly through most of the 1.0rcXX releases. Many of the issues addressed in these releases are either in highly specific cases, or have only a marginal effect. Overall, the reliability and functionality of Dovecot is on a level with commercial software.

• my experience at work - I'm talking about IT in the European Commission, with 20000+ users and a huge array of applications and development projects - is that no commercial software is free from "issues", whose impact depends on exactly what you are trying to do at a given moment. Everything has to be evaluated in your context, no matter whether it's Exchange Server 2003, Oracle 10 or Dovecot 1.0rc29.

• "mind share in the boardroom" is not the only possible goal for a project....

John

-- John Allen Bofferdange, Luxembourg allen@vo.lu http://www.homepages.lu/allen

Quoting Dean Brooks dean@iglou.com:

I have to agree with you on this. I'm relatively new with Dovecot and have been evaluating it for deployment in a production environment. I must say that Dovecot has the most unusual development method of a large-scale project I've seen.

I've seen about the same from other pre-1.0 software projects. The usual problem (and I have no idea if this describes Timo accurately or not, though it appears as such to me), is that the people (usually one person) heading the project are not experienced with large-scale software releases, and they make some simple mistakes. Often they look back years later and reflect on how they were "in over their heads" when they started, etc.

But, let me also say, that in the above paragraph I am thinking of 3 projects, all of which I use in production, all of which I love, all of which have worked out their problems after their first major release.

I would say, in general, these types of things are just "growing pains" and shouldn't be too surprising to most people. What would be surprising (and bad) was if they continued through the following releases.

Timo has already admitted his errors on the mailing list recently, and has already sought advice on how to fix them in the future, so I would think the future is bright for dovecot. And eventually, we'll all forget the past...

There have been so many show-stopping bugs in the past 10 releases that I wouldn't even consider this a candidate for a Beta release at this point, let alone a production release.

Actually, that is more due to the large number of RC cuts Timo makes, rather than the number of bugs in the code, IMHO. I've found several of the releases to be very stable for me, as have others. Of course, I'm very selective as to which I install and test; I don't test each RC that comes out (in particular, since I run mbox, I don't run ones that have only maildir fixes, etc).

I'm very appreciative of all the hard-work the author(s) have put into this, but I think at some point they need to take a hard-look at the way they develop and release distributions. It seems extremely sloppy and I know it's confusing to others besides myself.

I believe Timo already has done so, based on his comments on the list, and his requests for help on things like versioning systems, test suites, etc. If you've been reading the list over the last couple months, I think you would recognize this. But then, I don't speak for Timo.

-- Dean Brooks dean@iglou.com

-- Eric Rostetter The Department of Physics The University of Texas at Austin

Go Longhorns!

On March 30, 2007 4:05:55 PM -0700 Kenneth Porter shiva@sewingwitch.com wrote:

--On Friday, March 30, 2007 3:24 PM -0700 Frank Cusack fcusack@fcusack.com wrote:

...

...

This is why I'm still using 0.99. The RC's still look like betas and I have no idea which one (if any) is less a regression than any other.

They ARE betas. That's no reason to stay with 0.99. It's effectively beta as well.

In principle, a "release candidate" should be a gamma. It should be effectively ready for release, and distributed to check for awful show-stoppers.

Is 1.0rc29 stable enough to replace 0.99 from Fedora? Will I suddenly have a bunch of angry users seeing things break?

Will 1.0 be stable enough to replace 0.99?

You are going to have to do the exact same testing from 0.99->1.0 as you would from 0.99->1.0rc29. Caveat emptor with open source software; the responsibility is upon YOU to do your own testing.

It sounds to me like the reason you are running 0.99 is not because of any "rc" naming and/or lack of stability, it is because Fedora ships with 0.99. So you should just wait until Fedora updates it and not worry about the fact that the "rc" releases are misnamed.

So please, no more features in these rc's! Just lock it down and ship it and let people get some experience with it, so I'll know exactly what to expect when *I* install it.

People ARE getting experience with the rc's. That's why there's so many of them: feedback.

Why do you care anyway? (Not attacking you.) If 0.99 works for you, great!

-frank

On Fri, 2007-03-30 at 16:05 -0700, Kenneth Porter wrote:

--On Friday, March 30, 2007 3:24 PM -0700 Frank Cusack fcusack@fcusack.com wrote:

...

...

This is why I'm still using 0.99. The RC's still look like betas and I have no idea which one (if any) is less a regression than any other.

They ARE betas. That's no reason to stay with 0.99. It's effectively beta as well.

In principle, a "release candidate" should be a gamma. It should be effectively ready for release, and distributed to check for awful show-stoppers.

Is 1.0rc29 stable enough to replace 0.99 from Fedora? Will I suddenly have a bunch of angry users seeing things break?

It is stable enough. I've been using it in production, and each RC, with no issues. Really damn good software.

1.0.rc1 was released in June. Here's a quote from the release message for rc11 (November 4):

...

Hopefully the last RC release? As far as I know there are no major problems left now. If nothing big shows up, v1.0 should be out in a couple of weeks.

In rc27:

...

A few new small features and lots of index/mbox fixes. I've been heavily stress testing this release, so I think it should be about perfect. :)

*Features*?! In an rc?! No wonder there's no convergence.

Oddly, the new features don't seem to act up. Just little issues keep coming up.

Francisco Reyes wrote:

I really have to agree with Kenneth here. Specially after comments are made that the program has likely very few more bug fixes needed before going gold.. Adding new features, specially if they require any changes to the config file, makes little sense. Right!

I was tracking the RC branches for a while, until one day ten percent or so of the users here (we're on mbox) couldn't open their mboxes.
Rolling back didn't fix anything, and it took another five RCs to get things stable again.

So now I'm running a nightly build from the rc25 era, and there I'm going to stay until I migrate either to Courier or to Dovecot 1.0 (assuming it ever ships. We've been "real close now" for MONTHS...).

-- Jay Chandler Network Administrator Chapman University

Geert Hendrickx wrote:

What annoys me more (as dovecot maintainer for pkgsrc) is that the example config file changes with (almost) every release. The changes are mostly just in comments, but it makes users have to merge their configuration on every update.

What part of "Release Candidate" isn't clear here... ;-)

Seriously, until 1.0-final comes out, everything is up for grabs; though one would hope that the number of changes per RC is going to approach zero at some point... ;-)

John

-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748

On 30.3.2007, at 19.23, Geert Hendrickx wrote:

On Fri, Mar 30, 2007 at 05:47:30PM +0200, Robert Schetterer wrote:

...

HI Timo, you added the wiki in txt format to the docs dir, this again brokes my suse spec *g

What annoys me more (as dovecot maintainer for pkgsrc) is that the
example config file changes with (almost) every release. The changes are
mostly just in comments, but it makes users have to merge their
configuration on every update.

I hate how badly the configuration file updating works everywhere
(well, or at least in Debian). If the changes don't really change any
existing settings and won't conflict with the modified parts of the
config file, there's no need to ask anything about merging.

Why couldn't it work by doing a diff of the old and new default
config files, and then try to patch the changes into the current
config. If the patch succeeds, that's your new config. Of course if
the new config file really changes existing defaults, it shouldn't do
this without asking.

Geert Hendrickx ghen@telenet.be writes:

On Fri, Mar 30, 2007 at 05:47:30PM +0200, Robert Schetterer wrote:

...

HI Timo, you added the wiki in txt format to the docs dir, this again brokes my suse spec *g

What annoys me more (as dovecot maintainer for pkgsrc) is that the example config file changes with (almost) every release. The changes are mostly just in comments, but it makes users have to merge their configuration on every update.

In the end, Dovecot has not yet been released...

-- Matthias Andree

On April 4, 2007 6:35:27 PM -0700 Dan Price dp@eng.sun.com wrote:

We're still working on debugging why our Kerberos setup isn't working-- Thanks to Timo we have auth_gssapi_hostname, but we're still not quite there... our Kerberos engineers are looking into it.

There was a recent thread on heimdal-discuss talking about load balancing. (The issue with mismatched hostname is the same.) One person discussed how they fixed dovecot to work in their setup. It involved (IIRC) passing GSS_C_NO_CREDENTIAL to gss_accept_sec_context(). Maybe that thread will help you out.

-frank