Noel J. Bergman wrote:
Joachim Draeger wrote:
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.
Cool! I'm happy to know there are others committer testing unreleased
code and helping in the hard consolidation process.
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.
I understand you Noel, but it could be exactly the opposite thing. We'll
see after the vote will be completed. If it happen that I'm not the only
one that do not want so big changes in v2.3 branch then the one delaying
the release have been you with your not-discussed commit over a stable
branch.
I really don't know what others PMC member thinks about what to do in
v2.3 branch and what to do with 2.3.1: that's why a called a vote.
I also make it clear that I will retire the veto if a majority will
agree on something, so you should not be worried, unless you don't trust
the majority of this PMC, but then we should discuss that issue and not
branches or release version.
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.
This list is not so clear to me and it misses the javax security
property solution. Btw I think the vote "[VOTE] InetAddress unbounded
cache patch backport" already describe a bunch of solutions. If you want
to add further alternatives for 2.3.1 just add there so we can add our
votes to the alternative solutions too. Thank you.
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.
It may sound weird to you, but I'm also convinced that what I propose is
correct :-)
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.
NO, please, don't change v2.3 branch before discussing what you want to
do. And the "[VOTE] Using of 2.3 branch" thread is waiting for your vote
as the first step trying to solve this issue.
Oh wait ...
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.
What's the problem you have with "svn cp v2.3 next-minor" command?
I think I'm not asking too much...
As I explained I expect the license header issue to be solved as the
first thing (before branching) because it is needed both for 2.3.1 and
for next-minor (I still don't know if we'll make any or both of this
releases, but one of the tasks that will probably don't need votes or
discussions is the license headers one).
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.
There was 2 justifications, the other was technical. Furthermore I think
it is important to avoid committing over code that may be reverted.
Norman understood my objections/suggestions. He was probably not aware
of the duplicated feature he added.
Again, I'm inclined over retiring vetoes after necessary
attention/discussion has been brought over a topic, but keep saying that
I obstruct the work, that we don't leave you commit what you want in
whatever branch you want will not help the process.
Write proposals, call votes, and let's decide in a democratic way.
If we achieve more dynamism with the decisioning process we can help James.
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.
I think your duty is to vote. If you think people don't understand what
to vote (like it happened in past) try to convince them.
I think we proved that we accept also to repeat a whole vote after a
couple of months of wasted time because of a misunderstood vote, so you
shouldn't fear of people working against the democratic majority.
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
I fully agree. This is why defining an estimate date for branching will
help people understanding wether they have time to add a new feature
that will not destabilize the trunk or if it is better to wait for the
branch being created and apply to trunk after that date.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
