Noel J. Bergman schrieb: > Joachim Draeger wrote: > > >> Noel J. Bergman: >> >>> We should (and should have already) released v2.3.1 with the changes >>> > that I > >>> wanted to make to fix the defect, and to add one other change (the >>> > per-IP > >>> connections, which is really quite helpful). >>> > > >> Sorry I don't know which defect you are talking about. >> > > The memory leak is the main thing, plus I wanted to backport the per-IP > connection code. I have already done that privately, and have been running > with those changes since the day I posted the fix. JAMES, which used to > crash weekly, hasn't been restarted since the fix went in. > Thats the point.. "You" want to backport. Why not ask the others if they want to backport before we dedicide. Thats why i start the VOTE. I think Bernd suggest the right thing.. We should vote for every backport.
> >> If you think it is that important, why are you not trying to find a >> consensus? >> > > Because it has appeared to me that some Committers --- based on their > actions --- have been acting against any meaningful work on the v2.3 > codebase. I am not suggesting that they are doing this on purpose --- in > fact, I would bet that they don't realize that their actions have had this > effect. But we have had enough discord lately, and I really didn't have > time to argue about it. Stefano's e-mail this morning gives me some hope > that we can resolve the impasse, although there were mixed messages in the > several threads started this morning. > > >> It doesn't seem to me that there is no agreement possible. >> > > There are several choices: > > - Sun-specific properties which provide neither JVM portability, > optimal performance, nor optimal memory usage. This change > requires each user to replace the launch scripts rather than > just the james.sar file. > - A full backport of the code already in trunk for the next > major release. This introduces incompatible deployment > descriptors. > - A backport of all the code from trunk EXCEPT for the > deployment descriptor requirement, so we use a static > method, instead. > > I chose the latter, and most correct, solution. It was vetoed without any > basis in my opinion: the use of "static" was dismissed on grounds that are a > non-issue for the v2.3 code, and already resolved in the forward looking > code in trunk. As I noted to Stefano, I believe that we can again backport > the entire DNSServer from trunk, to minimize code differences, except that > we need to reintroduce the static method in order to avoid the deployment > descriptor change. > I think there whould be to much needed changes to backport the full DNSServer... Maybe setting the right property in the phoenix-loader whould be the best.. Please see the VOTE. > >> Everyone is willing to work on a bug fix release for 2.3. >> > > I would like to believe that, but so far anything that amounts to having a > real fix and any real enhancements to the v2.3 codebase has been blocked. > I'll tell you what: I'll try again, and we'll see if the code changes are > vetoed again. > > Oh wait ... > Again, i will try to help with 2.3.1. But im against commiting new features in the 2.3 branch. If we want to have new features out we should replace 2.3.1 with next-minor... IMHO 2.3.1 is a bugfix release and nothing more. > >>> And this ought to be done by renaming the v2.3 branch. If we >>> really need the original v2.3.0 code back, we can copy the tag again. >>> > > >> That is a trivial minor workflow decision which does not block anything. >> > > I agree that it should not, but look at the "[VOTE] Using of 2.3 branch" > thread this morning. > Why you think this is blocking ? I think it clear up things , nothing more. > >>> Do people really want to argue over 2.3.1 vs 2.4 because some minor >>> > feature > >>> is added? >>> > > >> No. It just seems that no one wants to invest his time. If someone will >> do the work, great! >> > > Once again, see the "[VOTE] Using of 2.3 branch" thread, where there are > votes to say that we must not have any feature enhancements in something > called v2.3.x. So apparently we do have to argue over the name in order to > release the thing, or even to commit code to it. I was going to review one > of Norman's changes this week, but I saw that he backed it out because it > was vetoed, too. One "justification" for the veto being that there is > already a veto on code in the branch, and it was therefore claimed that we > should not do any code in that branch at all until that veto is resolved. > > I revert it cause Stefano make clear that we allready have a fix for it in trunk and i just not notice it. So i prefered to have no duplicate features in trunk and backport the fix as it is. >> If you think you'll have enough man-power to bring a feature release >> based on 2.3 out of the door, just go on. No one will work against you. >> > > Go read today's threads. If you still believe what you just wrote, try to > convince me again. > > >>> As for branching from trunk, I agree with you. We don't need to copy >>> > trunk > >>> unless we have problems with people working on things in trunk that are >>> > in > >>> opposition to trying to make trunk reliable and stable. >>> > > >> No, no one here works in opposition to trying to make trunk reliable and >> stable. Everyone wants to make James a great product. >> > > That's not the point. If we are working in trunk to make it stable and > reliable, and then someone (me, you, it doesn't matter) wants to start > working on something that is not going into the next major release, and > which might destabilize things, we want to either move that new work into a > separate branch until the next major release is done, or we branch trunk to > a branch specifically for that upcoming release (this would be the most > likely step). > > --- Noel > > > bye Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
