Tests, scheduler and release..

[Danny Angus <da...@apache.org>]

I have a proposal to make.

1/ that Harmeet move the whole of o.a.j.testing (including the pre-existing potocol tests) into a proposal or first sub-directory of jakarta-james where it can be used to create an independantly distributable test suite.
2/ that the scheduler/watchdog and service issues be defered until after the release.
3/ we move on with the release as planned.

.. otherwise these will hold up what is regarded as being a much needed release of the 2.1a1 code.

I'd also propose that those concerned with the issues note them in a todo file in the root of the jakarta-james module to be addressed after the release.

Unless I am missing something important none of this was current before the release plan, none of it represents fixes for pre-existing reported bugs, and its deferal does not detract from the fact that this release marks an improvement in James over the 2.0a3 release.

I'm concerned that progress with the release will founder if we get involved in protracted debate (or worse..) on these issues, and I have a number of significant changes I am withholding until then for exactly these reasons.

d.


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

RE: Tests, scheduler and release..

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

> 1/ that Harmeet move the whole of o.a.j.testing (including the
> pre-existing potocol tests) into a proposal or first
> sub-directory of jakarta-james where it can be used to create
> an independantly distributable test suite.

Seems good.

2/ that the scheduler/watchdog and service issues be defered until after the
release.

Disagree.  More below.

3/ we move on with the release as planned.

Yes.

> .. otherwise these will hold up what is regarded as being a
> much needed release of the 2.1a1 code.

Instead we would hold up a needed and long awaited change?  I would rather
hash this out with Harmeet and see it committed, if that doesn't take too
much longer.  And I think that is realistic, since he specifically said that
he is willing to give his +1 if everyone else agrees.

> I'd also propose that those concerned with the issues note
> them in a todo file in the root of the jakarta-james module
> to be addressed after the release.

General question: HOW?  Do we submit a patch for the TODO file?

> Unless I am missing something important none of this
> was current before the release plan, none of it
> represents fixes for pre-existing reported bugs

Actually, this is the part that's not correct.  All of this is based upon
defects identified by Andrei months ago, and discussed on the list by he,
myself, Serge, Paul, Peter and others.  It was also discussed on the Avalon
Developers mailing list.  The same problem that was reported last week, and
verified by you, was the impetus for fixing this.  If Peter hadn't taken the
time to work on NNTP first, this would have been posted weeks ago, if not
longer.

> I'm concerned that progress with the release will founder
> if we get involved in protracted debate (or worse..)

Again, a general question: what is the mechanism for resolving a debate,
other than agreement?

> I have a number of significant changes I am withholding
> until then for exactly these reasons.

LOL I can imagine we'll be having fun.  :-)  Please note that I will be at
Colorado Software Summit the first week of November
(www.softwaresummit.com), so no fair making decisions that week!  ;-)

Not that I get a vote.  :-)

	--- Noel


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

RE: Tests, scheduler and release..

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

> It causes them to crash disastrously under any serious load.

So when Danny posts his load test code, we ought to be able to verify that
these changes do, in fact, correct the problem.  :-)

> This is not a little game to me.  I'm not interested in getting a beer
> from anyone - I want the server to work the way it should.

Hopefully, everyone takes James seriously.  Personally, I run James as our
primary mail server, with about 200 users receiving e-mail through it, a
bunch of mailing lists, and a bit more than a dozen domains.  I need for
James to work.  As a professional matter, I always look at code change as
introducing the risk of defects, and tests are important.  But when we can
reproduce a failure, fixing it is a good thing.  If people are to start
running James more widely, I don't think that we don't want it to fail in
such a resource constrained manner if we have the fix.

	--- Noel


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

RE: Tests, scheduler and release..

["Peter M. Goldstein" <pe...@yahoo.com>]

Danny,

> 1/ that Harmeet move the whole of o.a.j.testing (including the pre-
> existing potocol tests) into a proposal or first sub-directory of
jakarta-
> james where it can be used to create an independantly distributable
test
> suite.

+1

> 2/ that the scheduler/watchdog and service issues be defered until
after
> the release.

-1

IMHO there is no point doing the release until this issue is addressed.

This isn't a minor little problem.  This is a core issues that affects
every single service on the system.  It causes them to crash
disastrously under any serious load.

There hasn't been a single coherent objection to the changes proposed
other than "that's not the way it used to work".  Every question has
been answered, every issue addressed.  If there are more serious
questions/issues about the design/implementation let's hear them.  If
there's an objection other than "I don't see why we should change
things", then let's hear it.  If not, let's put the patch in and fix the
outstanding problems.

This is not a little game to me.  I'm not interested in getting a beer
from anyone - I want the server to work the way it should.

> 3/ we move on with the release as planned.
> 
> .. otherwise these will hold up what is regarded as being a much
needed
> release of the 2.1a1 code.

One of the reasons it's much needed (as the recent dialogue on the James
user list makes clear) is precisely the scheduler problem that we're
addressing.  Leaving it unaddressed only exacerbates the problem.

--Peter



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