Bernd Fondermann schrieb:
On 9/28/06, Stefano Bagnara <[EMAIL PROTECTED]> 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
system."
Well if this is the point of the user he can use one of the rc's ;-)
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 ;-)
Yes for me it should be closed as "won't fix". We can reopen it later
if we really feel like that... I not whould see it as stopper for 2.3
cause only noel have this problem.. So it seems to be not so common.
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.
Bernd
No Fear ;-) I just don't feal thats the right "way". I agree 2.3.0 is
much more stable then 2.2.0 , but for me realising with bugs is
something i know from microsoft and not from apache projects :-P
So let us fix the bugs release a new RC4 and after that publish final.
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
