OK, every take a deep breath and count to ten. Please keep one thing in mind. Everyone is acting in what they feel are the best interests of the project. Ceki is making changes he thinks are important. Curt is registering concern and reverting changes to keep things in sync. Everyone is voicing an opinion. We are all acting in a vacuum of information, in my opinion.

I have to agree with Jake. With all of the other interface changes I can think of (RepositorySelector, Configurator), there was some sizable discussion around what the changes were, what the changes would mean, whom they were most likely to affect, alternatives, and an assessment of benefit. If there was something like that for these recent appender changes, I missed it.

I'm not saying that these changes don't have benefit, but they were made in a vacuum, and the rest of us have been trying to figure out what is going on. I think that the process is working correctly, though the words are getting a bit harsh on both sides. Gump failures indicated that the changes were affecting projects, that is what it is supposed to be doing. Doesn't mean we have to revert the changes immediately; I believe that we have already stated that we will not be jumping all over ourselves to make sure Gump is happy all of the time. However, Curt (or anyone else, committer or not) is well within rights to bring up the issue as a red flag.

I have said before that changes to the Appender interface are a very big deal. Almost no one has written their own RepositorySelector or Configurator, but almost everyone has written their own appender. It was one of the first things I did when I installed and learned about log4j. That is the beauty of the log4j design, that I can write such a customized piece of code and still have it fit into the framework. With folks like Mark Masterson speaking up (author of SNMPTrapAppender), I think it is an indication of the level of reaction we can expect from the community in making a change in this area.

Doesn't mean that a change should not be be made. Means it should be discussed. We need to understand what the changes are supposed to be solving. What will be the affects of the change. When I hear terms like "life cycle management", I start to think there is more going on. We might decide, as a community, that we don't want to make those changes, that we would rather live with the issues and maintain the api compatibility. That is the process. Let's follow it. If it was a change to an area that doesn't get much focus or something inside the internal guts of log4j, we would not be having such a lengthy and somewhat heated discussion.

Ceki, I think we need to understand exactly what you were trying to solve with the changes. You might have already said this and I just missed the thread. The rest of us need to understand this.

-Mark



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



Reply via email to