He is not trying to RUSH the release.. he is trying to get more dev's and users which will take to installing 1.0 over an RC or BETA.

Either way a VERSION is simply a number we use to seperate the old from the new. What state the product is in really it relative. Putting 1.0 release looks better then RC for months on end.

I agree with making it 1.0 Final now...

or alternatively like what I am doing is running the RC and treating it like a FINAL release as I know that a version is superficial in reality only to seperate new from old releases.

my 1 and .5 cents..

--- Dominic Lepiane <dlepiane@irmacs.sfu.ca> wrote:

On Friday 21 July 2006 10:04, Marc Perkel wrote:

...

Just throwing out some thoughts here. I know Timo has high standards and is trying to make 1.0 bug free before calling it 1.0. But I want to argue for an earlier less perfect 1.0.

Dovecot is already way past the quality of most 1.0 releases. So it is good enough by common standards. No one really expects a 1.0 release to be perfect. But - some people don't consider a product ripe until it reaches 1.0. Once you cross the line then more people will pick it up and you will get more bug reports because of a larger base. This would actually accelerate the debugging process. And it will spur acceptance of the product and perhaps bring in more developer resources.

Generally 1.0 is still buggy. It is usually followed quickly with 1.0.1, 1.0.2 ... and then stabilizes. Then as more people ask for new features it spawns 1.1.0 which is somewhat buggy and then 1.1.1 and by 1.1.2 it's rock solid.

So - I'm not suggesting Timo go to 1.0 immediately. I'm just saying that I think it's pretty ripe and sooner is better than later.

My 2 centz ...

I think, as has been mentioned before, Dovecot is getting pretty close already. I want to get 1.0 adopted where I work and will be happier if there

are less problems with 1.0 than if 1.0 comes earlier and I have to start deploying patches already. Just because private sector vendors set the bar low doesn't mean Timo should. From activity on this list, it seems like we're within weeks or months no matter what so I say don't rush. That's soon

enough.

Like Marc, I'm not saying what should happen. I'm not suggesting we wait until the sun burns out for The Perfect Release, but the v1 release doesn't need to be rushed.

There's my 2 cents :D

-- Dominic Lepiane Simon Fraser University/IRMACS dlepiane@irmacs.sfu.ca

Timo Sirainen wrote:

I've again 125 unread mails in this list, but I don't think there's anything too bad left. SSL code is the only thing I'm concerned about, but I think I fixed that in CVS today.

I'm using beta9 in production and I've been reluctant to test the RCs because of an earlier post regarding new problems with SSL. I'd love to see another RC with the SSL fix so I can give it a try. I know I could build from CVS, but I'm lazy and addicted to ATrpms.

Of course you can do whatever you want, and whatever you do I will appreciate it, but I wonder if the Release Candidate stage is the right time to be rewriting sections of the code that already seem to work. Maybe you should have a stable fork and a testing fork of the code and try out new stuff in the testing fork? The stable fork would be nothing but bugfixes at this point. I understand that maintaining two versions is another layer of complexity that you may not want to get involved in though. Whatever, thanks again for dovecot and the support of it.

Mark

Axel Thimm wrote:

On Tue, Jul 25, 2006 at 10:07:47AM -0700, Mark Nienberg wrote:

...

Timo Sirainen wrote:

...

I've again 125 unread mails in this list, but I don't think there's anything too bad left. SSL code is the only thing I'm concerned about, but I think I fixed that in CVS today. I'm using beta9 in production and I've been reluctant to test the RCs because of an earlier post regarding new problems with SSL. I'd love to see another RC with the SSL fix so I can give it a try. I know I could build from CVS, but I'm lazy and addicted to ATrpms.

You can get the 1.0rc2 src.rpm from ATrpms, install it and replace the tarball with one created from CVS. Call it dovecot-1.0.rc2-cvs20060725.tar.gz.

Then change in the specfile the definition of "upstream" to be 1.0.rc2-cvs20060725 and also set the Release tag to 0_17.rc2_cvs20060725.

Then rpmbuild -bb and you're ready! That's all.

Maybe I'll give that a try. Thanks! Mark

On Mon, Jul 24, 2006 at 05:06:08AM +0300, Timo Sirainen wrote:

I've again 125 unread mails in this list, but I don't think there's anything too bad left. SSL code is the only thing I'm concerned about, but I think I fixed that in CVS today.

Timo,

could you please release an RC3 with this fix, so the public can test it?

Thanks,

Geert

Hi

I have a Nokia 770 which is a pocket sized Linux Wifi 800x600 tool.

I can easily search for and connect to WiFi hotspots and then look at
email in my home system (running Dovecot/Postfix).

This tool would work better if Dovecot would show only a subset of
the mail messages sitting in my home system (I only delete spam..).
Something like a sliding window that would show messages younger than
a week old (configurable slider horizon).

Is this a reasonable feature? Can it be done by just configuring the
existing system differently?

There are probably many users who access their mail with several
different systems during a day or week. A handy/cell phone with
email, or a pocket pda would have the same storage/access limitations
as the Nokia and their users would benefit from the same feature.

Sincerely,

Bob Gustafson

On Wed, 2006-08-09 at 20:18 -0500, Robert Cooper wrote:

That really sounds like an MUA function. Dovecot is just a IMAP/POP server; any filtering or limiting is either done at delivery (via sieve, procmail, etc) or by the client after retrieval.

Currently. Virtual folders will hopefully come some day to Dovecot.

On Thu, 2006-08-10 at 11:31 -0700, Frank Cusack wrote:

On August 10, 2006 6:14:00 PM +0300 Timo Sirainen <tss@iki.fi> wrote:

...

On Wed, 2006-08-09 at 20:18 -0500, Robert Cooper wrote:

...

That really sounds like an MUA function. Dovecot is just a IMAP/POP server; any filtering or limiting is either done at delivery (via sieve, procmail, etc) or by the client after retrieval.

Currently. Virtual folders will hopefully come some day to Dovecot.

Isn't that (shouldn't that be) a client-side feature?

I don't see why it should be. If you're using multiple computers it's easier to have the configuration in one place.

If it were a server feature, how would users configure it?

Sysadmin could configure global virtual folders (eg. Unread mail, Trash) and users could define their own with eg. directly modifying some config file or through some web UI. There are also at least 2 different IMAP extension drafts specifying commands how to create and modify them.

Quoting Bob Gustafson:

Something like a sliding window that would show messages younger than a week old (configurable slider horizon).

As other people already said, this is really a MUA function.

But it's also easy to do this on the server side, if you are using Maildir. Just create a cron job which regularly moves old mail into a subfolder.

On second thought, the duplicated messages to a second username has some flaws.

1. If I read a message on my Reduced View MUA, the read flag is set on the message in the second username directory, but not on the primary directory. The same goes for messages I delete. I will eventually have to do double work on all my messages.

2. There may be some problems with conflicting message UIDs between the same message in two username spaces.

3. If I send a 'reply' to a message from my second username, I can fake the return address as the primary username, but can I direct the 'sent' copy to my 'sent' folder on the primary username.

Having two usernames increases the complexity.

I think server involvement is necessary. Maybe Timo's mention of virtual folders is the correct direction.

Bob G

On Thu, 2006-08-10 at 09:52 -0500, Bob Gustafson wrote:

I was looking at sylpheed last night, but then I began to think more about the basic problem. There are two characteristics:

1. The sliding window or Reduced View is only for one viewer. I use several mail viewers (MUA) in the course of a day.

2. I don't ever want to download headers for all my mail to the Reduced View MUA. However, on other viewers, I do want to see all my mail. (Depends on the power of the underlying viewer machine. Pocket sized arm device is different from dual Xeon 3GB)

These requirements seem to indicate that some involvement is necessary on the server side. I have downloaded the IMAP protocol document (66pages) and have printed out 8 pages (index +) to see what IMAP gives me on this project.

---

However, I do really like your cron job idea. It could be invoked just after each fetchmail from my ISP. Maybe hacking fetchmail to duplicate new mail into a second username. Then run cron to delete older mail from this second username. Point Reduced View MUA to this second username.

Need to encourage the MUA to toss headers that are old too.

Goes along with KISS principle.

Bob G

On Thu, 2006-08-10 at 10:24 +0200, Jakob Hirsch wrote:

...

Quoting Bob Gustafson:

...

Something like a sliding window that would show messages younger than a week old (configurable slider horizon).

As other people already said, this is really a MUA function.

But it's also easy to do this on the server side, if you are using Maildir. Just create a cron job which regularly moves old mail into a subfolder.

Bob Gustafson wrote:

This tool would work better if Dovecot would show only a subset of the mail messages sitting in my home system (I only delete spam..). Something like a sliding window that would show messages younger than a week old (configurable slider horizon).

There are some drafts for such a functionality [1], btu they aren't finished/implemented yet.

As a sidenote, please don't use the "Reply" button of your MUA when you want to make a new message to some mailing list. A lot of folks down here use a clever mail agent that displays a "tree" representing the flow of conversation and those folks usually get a bit upset when they see a completely unrelated mail in the middle of some thread.

[1] http://www.google.com/search?q=draft-wener-lemonade-msgfilter

Cheers, -jkt

-- cd /local/pub && more beer > /dev/mouth