james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer ...@byteaction.de>
Subject Re: Type of next release
Date Tue, 19 Dec 2006 08:33:59 GMT
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message