logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Anybody home?
Date Wed, 15 Nov 2006 00:20:44 GMT

On Nov 14, 2006, at 1:04 AM, Elias Ross wrote:
> Yes, I believe I have.

You are listed at http://people.apache.org/~jim/committers.html.  I  
believe that I asked you to sign a CLA when we committed your  
"concurrent appender" contribution.

I could see that you might be frustrated by having patches stay in  
limbo for a long time.  I understand the issue since I have  
languishing patches in the APR queue for log4cxx.

I'm not sure if we discussed your submitted patches on the dev list  
or if I just had thoughts that I never communicated.  I think we have  
shown huge improvement on handling patches that have been simple and  
low-risk with the large number of languishing patches that were  
killed off with 1.2.14.  I expected that there would be a similar bug  
killing spree for the next 1.3 alpha release.  However, your patches  
were problematic in general and instead of diving in and trying to  
dissect them, I skipped over them for lower risk and lower effort bug  
kills.  I've re-reviewed some of your patches and made sure that my  
comments went into the bug entry.

Bug 34759 I would have to -1 in its current state since it removes a  
public member from a class and adds a new abstract method to an base  
class, both of which might break someone who is using an user- 
provided pattern converter.  I agree that the existing signature is  
ugly, but it can't be simply changed in either 1.2 or 1.3.

Bug 35758 seemed reasonable and only affected log4j 1.3, so I  
attached a patch file that corresponded with the earlier submission  
(but ignoring whitespace changes) and committed the change.

Bug 34945 didn't have a patch attached and so is hard to analyze.   
There seems to be an suggesting that something should be removed from  
log4j and if applications running on older JVM's that depend on the  
behavior they could add some more code.  It is not acceptable to  
break existing well-behaved apps by changes in log4j 1.2 or 1.3.   
log4j 2.0 would not be bound to that level of compatibility.

Bug 39971 changed default configuration values and would change the  
performance characteristics for existing apps.  Though the change may  
be beneficial for potentially a majority of apps using log4j, there  
are likely some apps that would not desire the change and you can't  
change the rules on them.  I'm a pretty strong -1 for the change on  
1.2, but might be persuaded to accept it on 1.3, ideally after the  
next alpha.

Bug 24159 has been a long running one and some changes from the  
various patches have been incorporated into log4j 1.3.  It would be  
good to close that issue and to spin out any missing parts into new  
bug reports.

Any other open issues that I've missed?

I've got to run, so I'm going to close out this thread.  I'll start a  
VOTE thread to add you as a committer when I get back.

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

View raw message