Noel J. Bergman wrote:
Bernd Fondermann wrote:
I don't trust 2.3.1 more than TRUNK or any other James snapshot.
That's really too bad, since we know from empirical experience that JAMES
2.3 + my patches hold up to years of real-world production loads. We have
some justification that 2.3.x are OK because we're not getting reports of
failures from end users. We have not an iota of demonstrable quality in
trunk save for your unit tests, which while gratefully acknowledged and
highly valued are *NOT* a sufficient indicator of real-world functionality,
nor do they in any way speak to performance or design issues.
I agree. (Except that Stefano must be credited for most of the unit
tests, actually, not me.)
I know what unit test are good for and what functional tests are good for.
And we all know that TRUNK is not tested in the small. So proposing to
expose it in the large while at the same time repeating the mantra of
"TRUNK implements Disposable" just doesn't make sense to me.
Well, then let me make this clear.
The proposal is based on the fact that every message delivered to the zone
will be disposable spam. Therefore, unlike performing some sort of faux
release without any basis, we will be testing in a risk-free environment.
Every message can be dropped, the database can be corrupted, the server can
leak memory and crash, and no one should care other than to fix it.
Then you are talking about a closed environment test, so do I.
As an example of why this sort of testing is the right thing to do, rather
than the idiocy of pushing out releases without real-world testing, consider
our current situation with SVN.
I never said we should release without testing beforehand.
It is you who is ignoring the fact we have a safe black box testing tool
right here in our project.
At the bottom line, I am happy that there seems to emerge some kind of
common goal to start from TRUNK and put it into heavy testing, be it on
a Solaris zone or locally using Postage. This is actually what I am
proposing for weeks and months now.
+1, count me in.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
