> Some suggestions to facilitate changes: > - Cleanup/redesign few things at a time not 5 things together
We would have. Except you keep blocking submission with -1 votes. And Noel keeps trying to figure out creative ways to appease you while keeping the momentum to improve the product going > - Keep scope as close to what is being attempted. We have been making more > design changes than a bug fix/cleanup needs. I'm baffled by your definition of "design changes". Basically you seem to think that any change that i) Removes a file ii) Reorganizes the methods of a file constitutes a design change. It doesn't. Of the changes discussed to date, the only one that is arguably a "design change" is removing the dependency on the scheduler. And that one was discussed ad nauseum over the summer. Everyone agreed, the scheduler had to go. Everyone but you still does. We have successful demonstrated tests of a scheduler-free James that runs like a bat out of hell. You haven't put the time and energy in to bolster your position - you haven't provided a .sar upon request. But we're still stuck on your -1. This behavior is exactly the sort of plodding thinking that let this trivial bug http://issues.apache.org/bugzilla/show_bug.cgi?id=5824 sit around for nine months. In short, if something doesn't work it doesn't constitute a design. It's only when i) An architectural issue has been discussed and documented ii) The basic functionality expected of that feature is provided (bugs are allowed, critical ones are not) that you have anything that can possibly constitute a design. The above criteria ensure that the proposed feature/arrangement/etc. works, and that understanding of the ideas involved is passed to the community. Otherwise, you've got nothing. I have a real problem with this sort of paralysis. It basically guarantees that the product goes nowhere. In the last three months the James community has, by group effort: i) Closed James as an open SMTP relay ii) Added a new service for fetching POP3 mail to a single mailbox iii) Improved the performance of the spooler by 50%+, depending on the configuration. iv) Removed multiple critical memory leaks v) Made the NNTP service come into line with spec vi) Made NNTP SSL and auth functional vii) Improved SMTP performance by 900%. Other handlers should see a substantial improvement as well. viii) Reduced heap size under load dramatically. ix) Fixed god knows how many other bugs At no time save this one did we debate whether these were "design changes". We examined the code base and modified it as necessary to make James work properly. In some cases files were reorganized or deleted, but this was almost never a real consideration as to whether the fix would be accepted. There was discussion in almost all cases of whether the proposed fixes were the right fixes, but the community came to a consensus and the fixes were made in short order. The current discussion, forced entirely by you, is easily the longest discussion we've had on implementing a bug fix during my time at James. And easily the least productive. As software developers, we are bound by our own sense of professionalism to maintain support for our published APIs until and unless we announce that the next version will not support them. This is a responsibility to our user base, and it is one I have championed vigorously. The same logic doesn't hold true for the details of our internal classes. Frankly, I don't care how the system currently works internally - that's not a criterion that we use to evaluate change. There is nothing sacrosanct about the current code. In most of the above cases the current "design" was flawed, in either a major (AuthService) or a minor (SMTPHandler) way. So they were fixed. That applies whether the original author of the code is Serge, you, me, or anyone else. That's the way successful software projects work. --Peter -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
