james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: When do we ship?
Date Thu, 28 Sep 2006 11:55:52 GMT
On 9/28/06, Stefano Bagnara <apache@bago.org> wrote:
> Bernd Fondermann wrote:
> >> I agree. We should not release until the website is ready. Btw, i don't
> >> think this will block us, because Stefano finished almost..
> >
> > As I see it we are not only having changes to the documentation but to
> > the code base as well, which leads us to RC4. RC4 could have been
> > RC1... for 2.3.1.
> There is nothing stopping us to release RC3 as 2.3.0 final if we want to
> do that. What happens in svn and what we want to release have not to be
> necessarily synchronized.
> I think that we should start a vote for RC4 as soon as possible (and
> after a brief test I will be +1 for RC4 release) and I would be -0 for
> releasing RC3 as 2.3.0 now.
> > We will always have bugs, even known bugs. So this should not be the
> > _only_ criteria for not releasing. It has to be weighted against the
> > nasty old bugs we have in the current stable release and if our user
> > base would be better off with the new ones instead of the old ones.
> > ;-)
> We waited more than 2 years to make this release and I we need to
> establish credibility for this release after 2 years of inactivity: imho
> a release with *known* bugs after so much time is a bad thing from a
> user perspective.

Ok, thats one perspective, the other is: "In all those years they
never put out a stable release fixing those bugs I have lurking here.
If they could at least fix _them_ and give me a better performing

> People already has an RC to use and we are actively supporting anyone
> trying to use 2.3.0RCs much more than people using 2.2.0. If we were
> name M$ then we would probably have released 2.3.0a1 as 3.0, 2.3.0a2 as
> 3.0SP1, 2.3.0a3 as 3.0SP2, 2.3.0b1 as 4.0 and so on... Imho the RC
> cycles ends when you close the known bugs and you can't find new bugs
> until the vote for the final release is found: we are not a business, we
> should care for quality more than money or number of downloads ;-)

Right. Perfect. But at some point you have to get pragmatic. You are
not really saying we should close every single little issue, are you?

> > The fixes we are doing now (docs int 2.3-branch, serial nos, mime
> > conversion disabling) are all neccessary, but should they hold the
> > release? Remember, we could publish a "known problems" documentation,
> > too.
> We have to evaluate each change: I think that the convert fix is safe.
> The serial fix is needed in trunk. I think we should add also in 2.3.0
> to make it more clear that the classes are compatible, but the change
> should be safe, also.

I am not saying they are uneccessary or aren't safe to do.
That's not my point.

> If anyone think we are ready for a release and want to start a vote then
> go ahead: AFAIK releases cannot be vetoed, so a simple majority is
> needed.

Tempting... I'll think about that. ;-)

> I'm currently -0 for a release for 2 causes:
> 1) I would like to include fixes committed by Norman today
> 2) I think that we should delay a few weeks trying to close JAMES-592:
> if there is a leak in the james sources that eat 2MB per day I would
> like to have it fixed for 2.3.0 final or at least to be able to say:
> there is a leak in dns/there is a leak when using the toprocessor mailet
> but we decided to not fix it for 2.3.0 so be aware of this problem (or
> something similar)

Fair enough. But set this into relation to the dramatic memory
consumption improvements which have happend over the last month. With
that in mind, releasing with JAMES-592 remaining open does not look so
bad to me. Nobody said this is a blocker, au contraire: Some of us
even wanted to close this thing ;-)

The whole reason for me to rant over this topis is: I am afraid we
might fall back into "small-fixes-every-day mode" on release branch
like it was a few months back on trunk.


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

View raw message