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: [PATCH/VOTE] - MX Chaining fix.
Date Mon, 11 Nov 2002 22:47:29 GMT
I think that a problem description in bugzilla is fine, and it is probably
underused.  But code ought to be self-describing, explaining WHY something
is as it is, not just what it does.

It is a shame that the source control and bug tracking systems don't
integrate better.  I admit to being out of the habit, but I suppose we can
all try to get (back) into the habit of putting the bug# into the CVS record
when we post a bugfix.

	--- Noel

-----Original Message-----
From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
Sent: Monday, November 11, 2002 15:12
To: 'James Developers List'
Subject: RE: [PATCH/VOTE] - MX Chaining fix.


> I've now read the bug report and the code.  Seems reasonable.
> However, there are useful comments in the bug report that
> probably ought to be in the code (or at least in the CVS).
> Specifically: "there should be a separate try/catch block around the
> transport.connect() statement, to handle connect errors separately
> from errors that arise during message transmission.  Connect errors
> almost always indicates that further SMTP servers associated with
> the MX record should be tried, while errors in message transmission
> are generally protocol-level errors that would occur with any SMTP
> server associated with the MX record (the exception being
> IOExceptions that indicate a failure in the underlying
> transport)" provides more elaboration than the current comments.
> I guess I'm not a big fan of having the bug database as the only (or
> best) source for why the code is as it is.

Ok.  I thought the comment I dropped in the code was sufficient, but we
can certainly cut and paste this into the code itself.

Personally I think we under use Bugzilla as a repository for useful
information.  This is exactly the sort of information a bug tracking
system is supposed to track.  :)


To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message