james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Type of next release
Date Mon, 18 Dec 2006 23:49:27 GMT
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
> > 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.

> 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
 - 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.

> 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 ...

> > 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.

> > Do people really want to argue over 2.3.1 vs 2.4 because some minor
> > 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.

> 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
> > unless we have problems with people working on things in trunk that are
> > 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

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message