Re: JAMES-574 -- which version?
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]
Re: JAMES-574 -- which version?
Vincenzo Gianferrari Pini wrote: I don't want this to become a religion war (by definition a matter of personal views :-) ). -0 is not a war ;-). In fact -0 is not a valid vote on code modifications. Only -1 and +1 are valid for code modification votes and 3 +1 are lazy consensus. So my -0 has the same validity of a non vote. There are a bunch of other committers, I'll be happy to accept the patch if it will pass the vote. I just want to be sure we follow a consistent procedure when working on our branches. Imo a -0 made this clear more than a long discussion. I'd like to put emphasis on the fact that there is no shame in having different opinions. My personal idean about what can be done and what can't be done in rc status is much less strict and I would accept this and more changes, but we already used a different rule in past so I think that -0 is the right thing at this point. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES-574 -- which version?
Stefano, I agree :-) . Ciao, Vincenzo Stefano Bagnara wrote: Vincenzo Gianferrari Pini wrote: I don't want this to become a religion war (by definition a matter of personal views :-) ). -0 is not a war ;-). In fact -0 is not a valid vote on code modifications. Only -1 and +1 are valid for code modification votes and 3 +1 are lazy consensus. So my -0 has the same validity of a non vote. There are a bunch of other committers, I'll be happy to accept the patch if it will pass the vote. I just want to be sure we follow a consistent procedure when working on our branches. Imo a -0 made this clear more than a long discussion. I'd like to put emphasis on the fact that there is no shame in having different opinions. My personal idean about what can be done and what can't be done in rc status is much less strict and I would accept this and more changes, but we already used a different rule in past so I think that -0 is the right thing at this point. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JAMES-574 -- which version?
Vincenzo Gianferrari Pini Resolution: Fixed Changed the log message level to debug when match fails. Key: JAMES-574 URL: http://issues.apache.org/jira/browse/JAMES-574 Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0 Fix For: 2.3.0rc1, 3.0 Uh ... we already voted on and tagged RC1, right? Are we going to re-roll RC1, or update JIRA to show this in RC2? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES-574 -- which version?
Noel J. Bergman wrote: Vincenzo Gianferrari Pini Resolution: Fixed Changed the log message level to debug when match fails. Key: JAMES-574 URL: http://issues.apache.org/jira/browse/JAMES-574 Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0 Fix For: 2.3.0rc1, 3.0 Uh ... we already voted on and tagged RC1, right? Are we going to re-roll RC1, or update JIRA to show this in RC2? --- Noel IMO this should have not been applied to 2.3 branch. We are in RC and we should apply only fixes to critical things. This is not really a bug, only an annoiance. We should put this stuff in 2.3.1 or 2.4 Otherwise we should change our current 2.3 policy, and we should have not used the rc tag. If we start applying similar changes I don't see why we shouldn't apply http://issues.apache.org/jira/browse/JAMES-515 Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES-574 -- which version?
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 Stefano Bagnara wrote: Noel J. Bergman wrote: Vincenzo Gianferrari Pini Resolution: Fixed Changed the log message level to debug when match fails. Key: JAMES-574 URL: http://issues.apache.org/jira/browse/JAMES-574 Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0 Fix For: 2.3.0rc1, 3.0 Uh ... we already voted on and tagged RC1, right? Are we going to re-roll RC1, or update JIRA to show this in RC2? --- Noel IMO this should have not been applied to 2.3 branch. We are in RC and we should apply only fixes to critical things. This is not really a bug, only an annoiance. We should put this stuff in 2.3.1 or 2.4 Otherwise we should change our current 2.3 policy, and we should have not used the rc tag. If we start applying similar changes I don't see why we shouldn't apply http://issues.apache.org/jira/browse/JAMES-515 Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES-574 -- which version?
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 Stefano Bagnara wrote: Noel J. Bergman wrote: Vincenzo Gianferrari Pini Resolution: Fixed Changed the log message level to debug when match fails. Key: JAMES-574 URL: http://issues.apache.org/jira/browse/JAMES-574 Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0 Fix For: 2.3.0rc1, 3.0 Uh ... we already voted on and tagged RC1, right? Are we going to re-roll RC1, or update JIRA to show this in RC2? --- Noel IMO this should have not been applied to 2.3 branch. We are in RC and we should apply only fixes to critical things. This is not really a bug, only an annoiance. We should put this stuff in 2.3.1 or 2.4 Otherwise we should change our current 2.3 policy, and we should have not used the rc tag. If we start applying similar changes I don't see why we shouldn't apply http://issues.apache.org/jira/browse/JAMES-515 Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] !EXCUBATOR:1,44c266bc43381548542968! signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: JAMES-574 -- which version?
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]
