I don't agree with Vincenzo about what is a bug and what could introduce
problems, btw this is a matter of personal views, so here is my vote:
-1 to reroll rc1: we already have the tag and an in-progress vote/test
(i did this once, we already agreed this was a mistake, so try to not
repeat this).
-0 to apply the patch for the next rc: i think we could live we a debug
logged as info in experimental code (disabled by default)
So I'm not vetoing it, but I'll change it to +1 if we'll find much more
bugs in RC1 and we'll have a longer release cycle for the next rc/tests.
Imho it does not make sense to create a new release for a log change and
delay even if few days our rc1 release, but I'm not the one that prepare
releases and I can't know if this will really delay things.
Stefano
Norman Maurer wrote:
I also see no problems to this in rc1.. i can reroll the release or put
it in rc2 ..
+1 for rc2
+0 rc1
bye
Norman
Am Samstag, den 22.07.2006, 19:55 +0200 schrieb Vincenzo Gianferrari
Pini:
I disagree. It was a bug, though trivial. And one year ago the behaviour
was like now after the fix (at least at info log level).
And if we find a bug, even not critical, whose fix is trivial, it can
and should be applied even to RC.
I would otherwise yesterday have voted -1 to "[VOTE] James 2.3.0rc1
Release", as it's been two weeks that I said that I was going to test
this weekend in my production system.
And JAMES-515 is not a fix to a bug, simply a cleanup that could
introduce problems to existing customers, and no perceived functional
advantage.
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
