dovecot - Jul 2006 - My view on 1.0 release and version numbering

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 ...

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 at irmacs.sfu.ca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20060721/fcd87f41/attachment.bin>

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 at 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 at irmacs.sfu.ca
>

On Fri, 2006-07-21 at 10:04 -0700, 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.
Pretty much the only reason why we're not yet in v1.0 is because the
heat has been +28C or something for the last few weeks and it has melted
my brains.

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.

And why do those nice apartments cost so much.. I sure could use a
50kEUR donation ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20060724/81abdb24/attachment.bin>

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

On Mon, 2006-07-24 at 05:06 +0300, Timo Sirainen wrote:
> heat has been +28C or something for the last few weeks and it has melted
FYI, We are between 35 and 38 here in Italy... :(

bye

Luca

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

Bob Gustafson wrote:
> 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
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.