Hi Ceki,
At 07:57 PM 5/1/2005 +0200, you wrote: > >I don't want to be dismissive but these are just a bunch of excuses. Sure, >the objections are all reasonable and all, but at the end of the day they >boil down to excuses preventing forward movement. >
By this definition, there is no such thing as a reasonable objection. If you are going to flippantly define everything as an excuse, how is it possible to have a conversation here? These types of statements really throw me for a loop. You say you "don't want to be dismissive", and then go ahead be dismissive. The fact that we were all taken by surprise by the immediate release of Log4j-1.2.10 is clear evidence that the "forward movement" we are "preventing" means only what *you* define it to mean. At a very minimum, I hope that, as an ASF member, you will respect the bylaws where everyone on the team has a vote on releases. Am I really reading this blatant disregard for others opinions correctly? I hope not! Very confusing!!!
[cut from your other response] >One excuse gone. 99 to go.
Unnecessary!
>Fortunately, this is open source where we can take our marbles and play >elsewhere. >
What the heck does this even mean? Are we still all on the same team or what? This kind of talk is just shocking coming from you!
Jake
>At 03:16 5/1/2005, Mark Womack wrote:
>>This is a spinoff of the discussion regarding slf4j and log4j. I reviewed
>>Curt's email on the 1.2 branch changes, and I am building on some of his
>>comments.
>>
>>I am not a member of the slf4j team, so I cannot speak to it's goals, etc.
>>As a log4j committer I have no opposition to it being directly
>>implemented/supported in the log4j classes, however, I think that doing
>>that implementation in the log4j 1.2 branch at this point is premature.
>>
>>Even though slf4j inherits everything from the former log4j UGLI
>>interfaces, it seems to me that part of its reason for existence is to
>>foster some common, neutral area where the members of the Logging Services
>>team, the JCL team, and others can work out whatever issues they felt they
>>could not work out within the walls of Apache. As such, I expect that
>>there are going to be some number of changes to the base slf4j
>>framework. Looking at the slf4j list archives, those discussions have yet
>>to really kick into gear. As Curt pointed out, slf4j has only existed as
>>an entity for a couple of weeks.
>>
>>Given that, I don't think that the log4j project should provide an
>>official implementation of the slf4j interface until:
>>
>>1) There is an official release from the slf4j organization. Basing our
>>official releases on a single slf4j beta release version is not good.
>>
>>2) There is demonstrated consensus from the slf4j organization. I want
>>some understanding that their (future) release version attains whatever
>>goals they have set and that they do not expect it to change significantly
>>in the future. If this was an effort within Apache, trying to achieve a
>>common interface/api, I would have the same requirements (though I think
>>it would be easier, quite frankly). I use the word "consensus" because I
>>expect there to be a group of developers deciding the slf4j fate.
>>
>>So, while I don't think we should allow an official release of either
>>log4j 1.2.X or 1.3 with slf4j changes until the criteria above are met, I
>>do think that providing some kind of slf4j log4j implementation based on
>>the current slf4j api would be fine. It should be a separate release from
>>either of the log4j releases and it would be appropriately labeled as
>>"experimental" or whatever we want to call it. There would be an
>>understanding that we (log4j) support the slf4j effort and we are working
>>with slf4j to provide an implementation, but that the work is in
>>progress. The work could be done on it's own branch. We can wrangle
>>through the details of implementation directly or an efficient facade. I
>>still want to understand what slf4j means to the JCL.
>>
>>I support the slf4j effort, especially if it solves the issues we have
>>seen related to JCL. Rushing an implementation of it, even though based
>>on the UGLI code that we know and love(d), is not right. Now it is with a
>>group that is outside of ours, in what appears to be a exploratory mode,
>>we have to take some care in that implementing it affects our log4j
>>api. Even once we release an official version, whatever form it takes, if
>>there are changes to the slf4j api, it should be treated as any other
>>supported log4j feature. I certainly would not want to start doing many
>>mini-releases of log4j around api tweak changes in slf4j. That is why I
>>want some assurance that the slf4j is "baked".
>>
>>I say "slf4j organization", but it is just wierd since everyone in that
>>"organization" is from log4j, and I suppose the JCL team(though I could
>>not find a list of committers for slf4j). It is still unclear to me
>>exactly why folks felt it had to move outside of Apache, but that is a
>>different discussion, and we are where we are.
>>
>>-Mark
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>
>--
>Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
>---------------------------------------------------------------------
>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]
