Ok, guys, don't you think all this has gotten a bit out of hand?

Ceki, apparently you committed code that cause incompatibilities with those implementing appenders against Log4j-1.2. There was no discussion of this beforehand and no one, but maybe Curt (because of the phone call), had a clue as to why this was done or what was being planned in the future. For that matter, we still don't really know what's being planned other than a basic commit comment and a statement that you got hung up on stuff but are working on it. I'm sure, functionally, it is something good (as usual). However, I take exception with both the lack of information and the tone of your emails. I was actually a bit taken aback because you are usually calm, cool, and collected. Hopefully it was an aberration!

Curt, I understand your wanting to keep compatibility. I tend to agree that if we can do it at the same time as adding new features, then we should strive for that. We broke compatibility with RepositorySelector's, but because there are few (if any besides the log4j-sandbox, which are now removed) outside implementations and it added real value to Log4j-1.3, it made sense. I'm not sure it does make sense here. I'm not saying I have a technical reason, I'm just saying I have a lack of information so I can't know if it does or not? Likewise, you couldn't have known either and, although I fault Ceki with a lack of information here, I believe you should have waited to hear directly from him for his reasoning before doing any reversion of code that he committed. No other committer could have given an authoritative opinion on whether to revert this change since only Ceki knew why the change was done. While Gump is useful, keeping it constantly happy is not as important intra-project communication. Don't let this keep you from continuing to be the active contributor you have been. You've been very helpful to this project and I hope that continues!

So, Ceki, can we expect some details on why the new changes in appender functionality make it impossible to keep backward compatibility? And if it isn't impossible (since Curt's modification was really not all that involved), why do you treat backward compatibility as such an unimportant issue? If it is possible to provide a smooth migration between 1.2.x and 1.3 with not too much effort, I think we should do that. Certain methods can be deprecated in 1.3 and removed in a later version. Then again, if this is simply a fundamental change in design and it will provide buko-benefit to users, then so be it, but explain yourself. Don't commit something that you know will set people's hair on fire, be silent about it causing people to scramble, and then write an abrasive "People" speech. You had to expect what happened, and if you didn't you were being extremely shortsighted.

That's all I have to say. I'm not trying to extend the discussion or lay blame. We're all fallible. Let's admit mistakes and take action to avoid them in the future rather than let it devolve to this. We've got a good group and a good community. Let's strive to keep it that way!


Jake



--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to