I don't want this to become a religion war (by definition a matter of
personal views :-) ).
In any case I agree that a small bug like this should not delay the
timings for releasing 2.3.0 final. Rc1 is already tagged and should be
released as is.
For me is a +1 to apply the patch in the following release, rc2 or final
or whatever may be.
If no other fix has to be applied from now, and if the rule is (I don't
know it is true) that no fix should be applied between the last rc and
the final, I won't create a case on this, and I can apply this 20 chars
patch to my own system in any case (five totally useless lines in the
log file per incoming message, doubling its size, is really annoying IMHO).
In the meantime my weekend test on my production system seems to be
going on quite well. On next Monday evening, after a real weekday of
activity, I will let you know. BTW this is why I asked Norman to wait
until Monday before releasing RC1, but he convinced me that it would
have attracted more testers ... :-) .
Vincenzo
Stefano Bagnara wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
