Serge, > I'm very much sick of 2.1. I don't know why it's taking so long, but > I'm not helping enough to complain.
You're not alone. It's taking so long because no one is helping. Just look at the last two months of CVS messages. > You dodged the issue of whether this was an important bug by saying it > was "discussed over and over and over again". Rather than doing so > indirectly, I'd prefer if it you directly answered whether you would > prefer to ship 2.1 with an unusable configuration (POP3 on, and using > file mailstore) or fix this bug. No I didn't. But to be absolutely clear, I would rather see 2.1 released now with this problem in place than wait to fix this bug. I believe that the appropriate way to resolve this would be with release note/documentation and a subsequent bug fix release (2.1.1 or 2.2). First off, I regard the statement that it makes file repository unusable as not quite accurate. The truth of the matter is that POP3 file repositories are not robust upon restart. Agreed, very bad. I certainly wouldn't want to use a file repository in a production, multi-user system. But not unusable as a simple test configuration. Or for proof of concept work. As I said, we can document the problem to make this distinction clear. Second, my view of release management is that you make a decision at some point in the process, and you stick with it. We made this decision. It was discussed. I don't think that fact is irrelevant. I think it's important. Otherwise there is the tendency to revisit every decision in the release process. Everything is game, nothing is settled. I think that's one of the worst ways to do a release. Third, much as some on the list won't want to hear it, there is a workaround. Use a database for your production systems. MySQL is free for personal use, reasonably easy to set up, and consumes minimal resources. Even the commercial license is very inexpensive. This is a realistic option that maintains the functionality. Compare this situation with the bug in 2.0a3 (and I believe in 2.0a2) where use of SMTP auth automatically opened up the server as an open relay. In that case there was no workaround whatsoever - SMTP auth is the only way for James to securely process relayed mail from arbitrary hosts - yet the release still went out the door. Finally, we don't even have a patch for this yet. While you've now volunteered to do this work, we don't know how much time/effort it will take to fix this. Will it make the upgrade more difficult by breaking file repository backwards compatibility? Will we have to document the upgrade procedure? How much testing effort will you be putting in to avoid new issues? Will it be equivalent testing to the amount done in the Q/A portion of this release (processing of ~1 million messages, for a total of ~2GB of disk space consumed)? The time/effort and the potential repercussions are totally unknown. Given the lateness in the process, I find that highly undesirable. I still believe that the correct solution is to document the issue and commit to a post-2.1 bug fix release (I said 2.2 in my previous email, I meant 2.1.1). That will allow us to resume development work on 3.0 and get a little momentum back in the game. You can continue with your work on patching the problem, and it won't be holding up other features. > I understand your frustration with a possible delay. But the feature is > glaringly broken, and in my mind it is worth fixing. I think holding > people accountable for knowing 100% of what needs to be done in an > onsite project is unrealistic at best, and doing so for a globally > diverse group of volunteers is even more dangerous. I guess. I don't know how you intend to do a release process if people aren't willing to take some responsibility. Certainly it's going to lead to a tepid feature set, continual alpha/beta releases because no one want to make the commitment to a released product, and a general lack of stability/performance. Having the project maintainers take some level of responsibility is the only way I know how to avoid these problems. And other projects with a "globally diverse group of volunteers" (i.e. the Apache web server) seem to do ok with this. All projects, open-source or closed-source, require a willingness to say at some point, "Good enough, push it out the door". That's how imperfect products both closed source and open source (just look at Linux, Apache, etc.) get distributed to a user base. Otherwise you might as well call the product Taligent and accept obsolescence/irrelevance a priori. At this point we're essentially done. Docs are imperfect, but have enough coverage so that they answer most of the questions we see on james-user. Some tweaking can occur post-release, if people feel like it. Noel has the marketing stuff lined up, and was supposed to return home yesterday night (I haven't seen him pop up yet, so I don't know if he's back). He was waiting for answers to questions about the mirroring issue, but had gotten no response to his enquiries as of Friday (I'm not sure what this says about the devotion of the ASF to the current mirroring scheme, but there you go). When he pops back, we'll see where he is with the mirroring, the marketing, and all of that. My view was that if Noel was set with his issues that we'd call for a final release vote and get this thing out the door. Obviously, that would be in direct conflict with your call to break code freeze. It's got to be one or the other. Let's pick. I vote get it out the door. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
