Unfortunately I cannot broadcast my feelings and confidence ;-)
Did you (Vincenzo, Serge, Noel) tried the current trunk or is it only a
feeling?
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.
Stefano
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
