Re: [Dovecot] 1.0.rc29 released

2007-04-04 Thread Dan Price
On Fri 30 Mar 2007 at 06:07PM, Timo Sirainen wrote:
 http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz
 http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz.sig
 
 Probably one more RC after this.

Hey all-- for those interested in deploying 1.0rc29, I just wanted to
report that I deployed 1.0.rc29 Monday evening and it has been
absolutely rock solid for the past 48 hours: zero core dumps, and I have
fielded no significant complaints in the past two days.  At this moment
we have 220+ processes in our dovecot deployment serving 103 users.

We did a little measurement and it's nice to see that dovecot is very
resource efficient; here is an aggregated view of all of the dovecot
processes we are using:

PROJIDNPROC  SWAP   RSS MEMORY  TIME  CPU PROJECT 
   100  221  179M  196M   0.6%   2:22:24 0.2% imap
   

So my runtime RSS per User is about 2MB.  Wow.  (In recent Nevada builds
we've refined prstat's ability to correctly measure RSS for projects,
zones, etc. so this number should be pretty accurate).

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.

I've gotten a lot of compliments about how stable and fast our setup is
compared with the old deployment-- those really should go to Timo.  Thanks!

-dp

-- 
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp


Re: [Dovecot] 1.0.rc29 released

2007-04-04 Thread Frank Cusack

On April 4, 2007 6:35:27 PM -0700 Dan Price [EMAIL PROTECTED] 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


Re: [Dovecot] 1.0.rc29 released

2007-03-31 Thread Kenneth Porter
--On Saturday, March 31, 2007 9:32 AM +0200 John and Catherine Allen 
[EMAIL PROTECTED] wrote:



- mind share in the boardroom is not the only possible goal for a
project


I was thinking of installed base, not commercial users per se.




Re: [Dovecot] 1.0.rc29 released

2007-03-31 Thread Gerard
On Saturday March 31, 2007 at 08:32:40 (AM) 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.

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.

There is no inherent danger in designing your own inbox structure,
provided that no other application attempts to access it incorrectly.
Dovecot would not be the first LDA/POP/IMAP application to do this.

-- 
Gerard

A psychiatrist is a man who goes to a strip club and watches the audience.

Merv Stockwood



Re: [Dovecot] 1.0.rc29 released

2007-03-31 Thread Matthias Andree
Dean Brooks [EMAIL PROTECTED] writes:

 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.

 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.

At the end of the day, the question is how to call it - if it's alpha,
beta, rc, all have different needs. Yes, it should have been alpha or
beta.

OTOH, if you've tried to get people to test release candidates, that is
hard enough. Most will silently wait for the real release ship when they
next update their $DISTRIBUTION (and after that complain that from 0.99
to 1.0 the configuration file format changed, or something like that).

So I still have some sympathy for Timo's many release candidates. I'd
rather he called a broken release RC rather than have showstoppers in
the actual release :-)

Features aren't good in rc though. But let's wait how 1.0 looks before
we complain :-)

-- 
Matthias Andree


Re: [Dovecot] 1.0.rc29 released

2007-03-31 Thread Bill Cole

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  
[EMAIL PROTECTED]




[Dovecot] 1.0.rc29 released

2007-03-30 Thread Timo Sirainen
http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz
http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz.sig

Probably one more RC after this.

* Security fix: If zlib plugin was loaded, it was possible to open
  gzipped mbox files outside the user's mail directory.

+ Added auth_gssapi_hostname setting.
- IMAP: LIST   didn't return anything if there didn't exist a
  namespace with empty prefix. This broke some clients.
- If Dovecot is tried to be started when it's already running, don't
  delete existing auth sockets and break the running Dovecot
- If deliver failed too early it still returned exit code 89 instead
  of EX_TEMPFAIL.
- deliver: INBOX fallbacking with -n parameter wasn't working.
- passdb passwd and shadow couldn't be used as master or deny databases
- IDLE: inotify didn't notice changes in mbox file
- If index file directory couldn't be created, disable indexes instead
  of failing to open the mailbox.
- Several other minor fixes



signature.asc
Description: This is a digitally signed message part


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Robert Schetterer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Timo Sirainen schrieb:
 http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz
 http://dovecot.org/releases/dovecot-1.0.rc29.tar.gz.sig
 
 Probably one more RC after this.
 
   * Security fix: If zlib plugin was loaded, it was possible to open
 gzipped mbox files outside the user's mail directory.
 
   + Added auth_gssapi_hostname setting.
   - IMAP: LIST   didn't return anything if there didn't exist a
 namespace with empty prefix. This broke some clients.
   - If Dovecot is tried to be started when it's already running, don't
 delete existing auth sockets and break the running Dovecot
   - If deliver failed too early it still returned exit code 89 instead
 of EX_TEMPFAIL.
   - deliver: INBOX fallbacking with -n parameter wasn't working.
   - passdb passwd and shadow couldn't be used as master or deny databases
   - IDLE: inotify didn't notice changes in mbox file
   - If index file directory couldn't be created, disable indexes instead
 of failing to open the mailbox.
   - Several other minor fixes
 
HI Timo,
you added the wiki in txt format to the docs dir,
this again brokes my suse spec *g

- --
Mit freundlichen Gruessen
Best Regards

Robert Schetterer

https://www.schetterer.org
Munich/Bavaria/Germany
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGDTESfGH2AvR16oERAkisAJ45K6MnCCR2XTSdEA7HUef2ihdA0wCeLpJz
XE+W4N94pM5vjpbXosgHiHY=
=oitS
-END PGP SIGNATURE-



Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Geert Hendrickx
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.

Geert


pgpsI2rExOMQR.pgp
Description: PGP signature


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Nicolas STRANSKY
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) -+-


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread John Peacock

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


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Geert Hendrickx
On Fri, Mar 30, 2007 at 12:35:09PM -0400, John Peacock wrote:
 What part of Release Candidate isn't clear here... ;-)

release candidate equals latest supported release in this case as well.

If they were 2.0 rc's, I'd continue running the latest 1.whatever release
until done.

Geert


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Geert Hendrickx
On Fri, Mar 30, 2007 at 07:35:40PM +0300, Timo Sirainen wrote:
 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.

I'm actually doing a merge dovecot.conf old-default new-default every
time, and it usually causes some conflicts due to changed comments.  They're
easy to resolve, of course, but it could be avoided.

Geert


pgpcP3Q3sMDjc.pgp
Description: PGP signature


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Dean Brooks
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.

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.

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.

--
Dean Brooks
[EMAIL PROTECTED]


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Frank Cusack
On March 30, 2007 4:05:55 PM -0700 Kenneth Porter [EMAIL PROTECTED] 
wrote:

--On Friday, March 30, 2007 3:24 PM -0700 Frank Cusack
[EMAIL PROTECTED] 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


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Frank Cusack

On March 30, 2007 7:31:15 PM -0400 Dean Brooks [EMAIL PROTECTED] 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


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Kenneth Porter
--On Friday, March 30, 2007 4:41 PM -0700 Frank Cusack 
[EMAIL PROTECTED] wrote:



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.


Actually, no. A few people keep up with the latest rc's. A lot of people 
will install 1.0. I try never to be the first lemming over the cliff. I 
wait to hear the sounds of the others splash, to see where the rocks are. 
With a proper 1.0 release, I can have high confidence in knowing what bugs 
to expect before I install it. I don't have that confidence with an rc 
tried by only a handful and then rapidly replaced with its successor.


Windows Server 2003 Service Pack 2 came out a week ago. I'm leaving it in 
the unapproved queue for a couple weeks, maybe a month, to hear what 
happens to the early adopters. I'm quite sure it will have its share of 
problems, and I can live with that, as long as I have some idea of what 
they are.


Note that I'm a small shop. I don't have the luxury of a parallel testing 
environment like some corporation with hundreds or thousands of employees 
and the IT budget to match. I rely on the experiences of other admins with 
the deep pockets to do that sort of thing.



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.


It's because lots of people are running this version, and it's a known 
entity.



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


Because there are features in 1.0 I'd like to start using. But I don't want 
to have to wait for tomorrow's feature's testing before I can use 
yesterday's features.


Lock down 1.0 and ship it. Most people realize that a dot-oh release is 
going to have bugs. Let the wider community start getting experience with 
it. Don't do any more coding on this branch except bug fixes.


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Kenneth Porter
--On Friday, March 30, 2007 4:52 PM -0700 Frank Cusack 
[EMAIL PROTECTED] 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. 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.


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Frank Cusack
On March 30, 2007 5:04:58 PM -0700 Kenneth Porter [EMAIL PROTECTED] 
wrote:

--On Friday, March 30, 2007 4:52 PM -0700 Frank Cusack
[EMAIL PROTECTED] 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


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Kenneth Porter
--On Friday, March 30, 2007 5:22 PM -0700 Frank Cusack 
[EMAIL PROTECTED] wrote:



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.


If you mean a single developer might scare away users, I don't think that's 
the case. Plenty of popular software is developed by a single person or a 
very small developer group. And with open source, the loss of the developer 
doesn't mean that the application gets orphaned.



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.


My concern is not quality but predictability. There's a reason 0.99 and 1.0 
software is poor quality: Few people are willing to risk using it, so it 
doesn't receive widespread testing. More will use 1.0 than 0.99, and more 
yet 1.0.1. The rc on the end of the current dovecot is little better than 
0.99 to those who insist on a 1.0. (It's psychologically better, but only 
just marginally better.)


I also don't seek more users out of some kind of popularity vote. I'm 
looking for the many eyes effect. With more people using it, more issues 
get identified. It's like sending an army of bots over a minefield, so I 
don't have to be the one losing a leg.


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Eric Rostetter

Quoting Dean Brooks [EMAIL PROTECTED]:


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
[EMAIL PROTECTED]


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

Go Longhorns!


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Eric Rostetter

Quoting Kenneth Porter [EMAIL PROTECTED]:


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.


While, is there really no one between the boardroom and the avant garde
hobbyists?  I didn't realize there was such a void between those levels...


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


Yes, well, of course.  We all know that already.


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.


That is simply documentation, not really a feature.  And it is actually
fairly normal to add and refine documentation during a RC release.

I agree in general with the no more features requests, but docs are
really a whole different thing.  Most shops are working on the docs
right up to the last minute for every release.

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

Go Longhorns!


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Peter Hessler
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 
:[EMAIL PROTECTED] 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


Re: [Dovecot] 1.0.rc29 released

2007-03-30 Thread Aria Stewart
On Fri, 2007-03-30 at 16:05 -0700, Kenneth Porter wrote:
 --On Friday, March 30, 2007 3:24 PM -0700 Frank Cusack 
 [EMAIL PROTECTED] 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.