james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: Milestone from trunk
Date Fri, 02 May 2008 20:22:59 GMT
On Fri, May 2, 2008 at 9:29 PM, Noel J. Bergman <noel@devtech.com> wrote:
> Robert Burrell Donkin wrote:
>  > there is no prospect of releasing trunk without Noel's active support.
>  I hope that's not actually the case, but regardless, what does the PMC think
>  of the following?
>  Trunk is simply not trustworthy.  Anyone who would consider releasing from
>  trunk would do little to improve my opinion of said person's competence to
>  make that judgement.  Frankly, I consider a "milestone" from trunk to be
>  less than a bad joke, and would vote -1 on the grounds that no one can
>  consider trunk even close to being supportable.  You and Danny have recently
>  said almost the same thing about trunk being unsupportable.  So what is the
>  point of a milestone?  We already do nightly builds.  Anyone who wants to
>  jump off a mountain in the dark without a parachute and pray for the best is
>  invited to try the nightly builds.
>  That said, there are several things that we could do it improve trust in the
>  code.  One is the plan that we had discussed at ApacheCon: start from known
>  good code -- the JAMES 2.3.x codebase -- and incrementally merge parts of
>  trunk into it as they are reviewed.  I consider that to be a good and viable
>  option, and would have started on that already were it not for my own
>  server's failure last week, and the SVN issues this week.
>  Second is to get people to review trunk en masse.  I don't consider that
>  likely, but if everyone wants to give it a shot, I'm willing to be
>  surprised.
>  However, simply reviewing the code won't come even remotely close to cutting
>  it.  One reason why the trusted code is trusted isn't just that it has been
>  reviewed, but that it has been EXTENSIVELY tested in production over a long
>  span of time.
>  So regardless of which approach we take, and certainly crucial to any
>  attempt to evaluate the code quality of trunk, we need to hammer at the
>  build.  And not just within a sanitized cleanroom network, which is what
>  prevented Stefano from seeing the problems staring those of us who actually
>  use JAMES in the face.
>  So what I propose is that we setup a JAMES zone, and start to deploy JAMES
>  in that zone.  That will be published in the DNS, and quite shortly we
>  should start to see a lot of connections coming to it as millions of
>  spambots start to exercise JAMES for us.  So we'll have a built-in load test
>  running, courtesy of the botnets, and we can just watch the build work or
>  crash in flames without any concern for lost messages.  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.  We could, for example, setup an SMTPS handler, and allow PMC members
>  to send via it, or alternatively, allow relaying only when the connection
>  comes from p.a.o.
>  This would be a really good thing for helping us to improve trust in the
>  code, both now and as it evolves.

I don't trust 2.3.1 more than TRUNK or any other James snapshot.
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. Noel, you
are inconsistent ;-)

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.

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

If we are positive with local tests we can deploy to a zone. But
without testing locally before, I think this is unprofessional.
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

Additionally - Noel, if you are aware of any specific, reproducible
problems with TRUNK, please take the time and document these on the
mailing list or in JIRA.

In short: +1 to deploy to a zone _after_ testing it sufficiently locally.


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

View raw message