james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Pushing towards a RELEASE
Date Thu, 04 May 2006 13:26:03 GMT
Unfortunately I cannot broadcast my feelings and confidence ;-)

Did you (Vincenzo, Serge, Noel) tried the current trunk or is it only a 

I understand that it is easier to know if the code is "production ready" 
or not when you are the one that did the changes, but I also think I 
cannot do much more than writing new code and test things I use in my 
real world applications.

I mostly know when I commit new code if that could cause problem, but 
this is not always the case. I cite 2 things I reverted for the next 
alpha 2 release:

1) 8bitmime stuff: From a conceptual level it was already supported. I 
enabled things locally and started a few tests. I found problems and I 
added patch and put them in my (personal) server. It worked fine so I 
committed it. After the release of James 2.3.0a1 people reported problem 
with mail sent by james to other mail servers (supporting 8bitmime). I 
investigated the bug and found a javamail bug. So I removed the 8bitmime 
support from RemoteDelivery. We have then received further reports and I 
found we hit the same javamail bug when we accept mail in 8bit and try 
to send it as 7bit. So this is a javamail bug. I updated the bug status 
to blocker to remember that we cannot make a release with that code 
while I did more tests. I always thought this was an easy patch and with 
no possible troubles but I was wrong.

2) JDBC store "streaming". I wrote the code to read and write streams 
from db, I wrote tests and I put the code in production in my personal 
server (against mysql4.1 and using connectorj5alpha). It worked. I knew 
that the change was critical so I decided to commit it in 2 steps: first 
the writing code, then the reading code. I also wrote a message to the 
server-dev list to let people know that the trunk was not 
production-ready because the new code was experimental. We received 2 
bug reports: one was related to dbfile (i didn't test dbfiles) and fixed 
asap, I was not able to reproduce the other. I started working with 
Norman to find out the problem because no one else was reporting the bug 
but I have been not able to reproduce the problem. No one else reported 
the problem (has anyone else tried it??) but I decided to mark it as a 
blocker. I also added an option to reenable the code because if we want 
to solve the OutOfMemory issues this is the only way we can follow.

Noel wrote he wanted to push a release, so I applied patches 
(revert/workaround) to avoid the 2 issues so we are now able to test the 
code for this alpha 2 release.

The point is: we don't have 100% test coverage and no one is willing to 
write all these tests, so the only way to be confident about the code is 
ask with people working on the code what is the current status and test 
it personally. So download the current trunk, test it and let's release 
a 2.3.0a2.

If you have any suggestion to improve this workflow or any hint on to 
avoid the above problems I'm happy to hear!

James 2.3.0a1 has been a good release if you consider it was an alpha: 
we had only one major bug (8bitmime).

Personally I feel happier with the current trunk than with the 2.2.0 
final. We solved at least 2 critical message corruption bugs from 2.2.0.


PS: I'm going to put current trunk in production tomorrow. If I don't 
find further problem I'll tag it as 2.3.0a2 and start the vote for the 
release, so you can test it and vote.

Vincenzo Gianferrari Pini wrote:
> Noel J. Bergman wrote:
>> What does
>> it say that neither Serge nor I are running the current code in 
>> production?
>> I normally ran trunk in production, but there were so many key changes on
>> top of one another that I was no longer comfortable putting trunk into
>> production.
> I feel the same. The version I have in production is trunk as of June 
> 24, 2005 plus my changes to the bayesian analyser.
> In the past I always tried to run the current code in production.
> Vincenzo

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message