james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Milestone from trunk
Date Fri, 02 May 2008 22:29:00 GMT
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.

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

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.  Because of an emergency, an untested
configuration of a new (for this purposs) but supposedly stable operating
system and new hardware was precipituously put into place without any proper
testing.  So we have had crash after crash for a week, despite the best
interests of an entire team of very talented people spending tremendous
hours on the singular task of keeping an SVN server running.

In the past, I have been the primary real-world tester before a release ever
happened.  I do not trust trunk to be other than disposable.  The above
environment would provide us with a means for doing real-world testing, and
establish a level of trust in the code necessary to even contemplate putting
it into a critical position (pending fixes, etc.).

> I wouldn't like to see James loosing its credibility and trust caused
> by a bug or untested feature causing it to sent out email to
> everywhere from an apache.org zone.

Which part of:

> > We will need to be careful to initially DISABLE the ability to send
mail,
> > and open it up very carefully to MAKE SURE THAT WE DON'T accidentally
> > create a relay of any kind.

was not clear to you?

> We already have tools for load- and integrity-testing a mail server
> locally and without exposing it to the outside world right here at our
> fingertips.

That sort of thinking led Stefano to push to rush out v2.3.0 over my
objections that there was a critical memory leak.

> Actually, I think a release labelled as "milestone" and thus clearly
> attributed as "not-production-ready-yet" is more clever than actually
> exposing it in a production-like environment on a solaris zone
> untested.

Wrong.  Fundamentally, categorically, wrong.  We do NOT put our stamp of
approval, even one so "weak" as "milestone" on untested code and screw over
our users, who trust us, because some folks here don't understand the
fundamentals of stability and reliability.  JAMES is not a game or hobby.
E-mail service is business-critical and time-critical.  It tolerates near
zero defects.

	--- Noel



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


Mime
View raw message