Serge, > We have a release process... we voted on a release plan, and the code is > now > frozen. If we see a bug, we raise it, discuss it, and vote whether we > should fix it. You don't like this process and want to use your own, and > I > can't get around your veto.
Excuse me, but this is exactly the process we discussed and approved. Pre-existing bugs were evaluated and judged. We had an explicit discussion about this bug. New bugs are raised, discussed and submitted for evaluation by their discoverers/committers. Some have been approved (the Oracle resource fix) some were held off on (the deluser problem). Opportunities for discussion were always there. There is no process of "my own". Your implication is erroneous. We, not me, decided to put it off. Now you're asking, at the 11th hour, to revisit the decision to put it off. Ok, let's agree that you have the right to make that request. In fact, you've already made that request. What you've really got a problem with is that I disagree with you. You're annoyed that I don't agree with you that it should be reversed. In fact, it's even worse that that, because I'm advocating a third way that would allow us to support the user base without further delaying the release. So I'm willing to grant that the bug should be fixed, and your problem is that I feel that getting 2.1 out the door is a value above and beyond fixing this bug right now. And why exactly does this make me a bad, bad man? I'm not going to try and vilify you here in the interest of winning points. I believe that you believe that your proposal is the best path for James. I just don't agree. Why you find that so inconceivable is beyond me. > You're just not making very many friends by changing rules and -1 > everything > you don't want to work on. I voted to support the 2.1 release plan and > code > freeze without new rules being introduced. No rules were changed, nothing was altered. See the above. And I'm certainly not "-1 everything I don't want to work on". What I am doing is tightly gating the 2.1 release to try and move it out the door. > Anyway, I was very supportive of someone bringing rigor to our testing, > documentation, and release process. I'll admit I'm upset this moment, but > I'm going to find it difficult to +1 to any more of your release plans > with > the way the past month has gone. Ok. Quite honestly, given the failure of anyone to actually contribute to the release plan, I doubt I'll be proferring any new ones up. This has, as may be apparent to you at this point, a tremendously disheartening experience. I find it sad that the developers on this list (for the most part) cannot muster up a few hours over the course of months to advance the pieces of the project that, while they might not be the center of their interest, nonetheless make the product more appealing to the end users and hence benefit the whole. That, while many may talk a good game, few seem willing to put in the actual effort. Certainly it's helped undermine my belief in the effectiveness of open source development. > And finally, this is a simple bug and I'm not going to sit here and talk > for > days about how to go about this change... I said this is a quick fix, > maybe > a bit more to support backwards compatibility. I think you're being > clearly > beligerent about the QA issue... pop3 file system DOES NOT WORK!!! To > your > comment of it being usable as a simple test configuration... who downloads > a > mail server for a simple test configuration? By comparison I suppose you > would say if the SMTP handler couldn't support remote connections, that's > acceptable? I've already explained my view of this bug. You don't like it, that's fine. You disagree with it, that's fine. That's your prerogative. Feel free to try and convince me otherwise. Or don't. But this trivialization does you little credit. There is certainly no need for you to spend days talking about the change. Go off and fix it if you want. As I'm trying to make crystal clear, there is absolutely nothing stopping you from doing so. Speaking as probably the only committer who does run the file repository on any system (I use it for one of my low traffic domains, and also for testing file repository issues in James) I can confirm that the bug behaves exactly as I stated. Provided the server doesn't restart (inducing renumbering), things work ok. My server has been running for weeks without a problem. It's a robustness issue and, as I granted, a nasty one. But there is a work around, which to me means it isn't critical. Sorry you disagree. As far as the above analogy, it is false. Your comparison is false precisely because if the SMTP handler didn't accept remote connections, there would be no workarounds. False analogies rarely advance arguments. I'm not sure why you don't see the difference. I certainly don't feel I'm being belligerent about the QA issue - what I'm doing is illustrating what real tradeoffs are involved. You can't seriously believe that a change to the file repository that is so fundamental isn't going to require at least a little testing, can you? Especially considering backwards compatibility issues? It's not like it will be months, but it will probably be at least a week. > > 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... > > Heh, well if you're expect us to need another vote to make the final > release, you can expect a very loud -1 from me. Ok. That's your prerogative. As I said, these two views are in conflict. I mean I don't know what to tell you Serge. I'm not '-1' voting for my health. Or out of spite. I'm trying to get a reasonable product out the door. Something I can be proud that my name is on. That's the reason I spent much of my Thanksgiving vacation writing user docs. It's certainly not because I enjoyed it. I believe James can be a valuable product. I'm also trying to get us to institute a process that will lead to better future versions. I've already presented what I think is a very reasonable alternative that doesn't block getting the file repository fix out. You seem to regard it as anathema - so much so that you haven't even addressed the option directly. Honestly, when I looked at 2.0a3 several months ago I saw promise, but not much motion. As a product, James was slow, died under load, poorly documented at a developer level, and contained tremendously incomplete/confusing user docs. It had a number of bugs (including this one) that clearly had gotten no attention. Patches attached to some of the bug reports hadn't even been reviewed by committers and introduced into the code base. Patches on the mailing list languished. The changelogs for 2.0a3 and 2.0a2 seemed unambitious for nearly six months of work. Now look at the changelog for 2.1. It's a similar approximately six month period. Look at the kind of changes we've seen in the code. That's despite some rather drawn out arguments. And the greater changes in the product (i.e. user documentation, marketing) that have come with 2.1. Now we've got a bug situation that's under control - each bug has been evaluated and discussed. Most were fixed. The SMTP processing is fast (900%) improvement, robust (no crashes under continual heavy load), fairly well documented for developers, and has the core of a decent set of user docs. Response to users has improved, and all outstanding patch submissions have been evaluated (most of them being incorporated in the product). So something seems to be improved. > I'm so tired of always arguing within this project. Why can't we all just > get along? We've had a number of users immediately say they want this bug > fixed when I asked for a vote to do so.... why do we have to argue so > much?!? That's real life. Users always want their bugs fixed immediately. Understandably so. As I mentioned earlier, this was my job for a long time. Continuing engineering. So I'm more than familiar with users' desires. But there are questions of completion, stability, robustness, and testing. It's easy to ignore these but you do so at your peril. Users aren't any happier if you fix the bug you know about and introduce three more in the process. Avoiding the latter situation requires some care and, more importantly, some time. It is my belief that we are late in the game on 2.1 and that the time isn't there. People are already antsy to get on with 3.0 - and understandably so. None of this stops you from working on and posting your patch. Users on james-dev (the ones who requested it) could download it and apply it to their own systems. None of this stops you from preparing it for inclusion in a 2.1.1 release. There are already a few other bugs (dot-stuffing, deluser) that would be good candidates for such a beast. If properly restricted, this could be a very quick release (a la Phoenix 4.0.1 and 4.0.2). As far as arguments go, they're a natural product of people who have diverse opinions and feel strongly about them. Quite honestly, I haven't enjoyed these discussions myself. But that doesn't mean I'm going to cave to every whim on this list. In each case I've proferred arguments as to why I feel the way I do. When asked, I've elaborated on my reasoning. While I'll admit I've been terse, and certainly my frustration has come through on more than one occasion, I've also tried to work for the good of the product and the community. It saddens me that you can't see that last part, because that's the part that has made the arguments tolerable. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
