Code breaks, we fix it.

["Noel J. Bergman" <no...@devtech.com>]

> "If there are number of changes(as half a dozen protocol server
regressions
> indicate) the process is to have a proposal not checkin into head. Checkin
> into head impacts everyone and causes 11th hour headaches for the
release."

> This means the right process has not been followed and is causing all this
> mess.

Harmeet, if you are dredging up past errors, then use them to talk about the
process, not about the person.

The process is that everyone tries to submit good code, but bugs happen.
So, we report the inevitable problems, and we fix them.  We report a defect
against the code, not a defect against the coder.

Harmeet, code breaks.  Accept it and move on.  There is at least one person
on this list who can attest to my working to 5AM to fix one fatal flaw after
another because the people who checked in code had tested it in their
environment, and it didn't work in mine (or generally).  I was not working
at 5AM for giggles.  This was before I had setup a separate test server (I
know, I know ...), and I'm watching my live server die!  Believe me, there
are a few people whom I'd have liked to lynch over those bugs.  But you'll
never find so much as a hint of my ire in the archives or the CVS, nor do
they have any idea that I might be referring to them; in fact, with one
exception, not even I remember who was responsible for each 5AM emergency
repair session.  Because after I finished disemboweling them in absentia, I
simply fixed the bug and submitted the patch.  And I certainly learned my
lesson about a test server (and backing up the SAR file).

Yes, James needs a test suite.  You have volunteered to work on it.  I
recommend that you do so.  And you should EXPECT bugs.  Having a test suite
doesn't prevent errors.  It allows them to be caught more rapidly, more
precisely determined, and more readily repaired.

> Agreed, I have already promised to test more. Hopefully others will to.

> > The point is that the presence of improper conduct on the
> > mailing list is not a license to contribute more of it.
> > What we need to do is eliminate it, period.

> +1000 on it.

Good.  It is absolutely imperative that everyone uphold that standard.

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>