Re: [HttpClient] Logging wars revisited for the last time (really)
Folks, I started the poll on the logging tool for HttpClient 4.x on the user list. If you feel strongly about a particular option, please make your opinion known. Oleg On Fri, 2008-05-23 at 13:12 +0200, Oleg Kalnichevski wrote: > On Fri, 2008-05-23 at 11:09 +0100, sebb wrote: > > On 23/05/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > > Folks, > > > > > > We finally need to make a decision on the logging toolkit we are going > > > to use in HttpClient 4.0 onwards. > > > > I agree that the decision needs to be final - but first it has to be static > > ;-) > > > > Right you are ;-) > > > > > http://issues.apache.org/jira/browse/HTTPCLIENT-416 > > > > > > Here's my suggestion about the course of action we should take > > > > > > (1) I'll start a poll on the user list about popular opinion on the > > > matter and propose three alternatives: > > > > > > * keeping commons-logging > > > * migrating to slf4j > > > * migrating to j.u.logging > > > > > > (2) Let the poll run for a week or so and get the users express their > > > preferences and opinions. > > > > > > (3) Tally the votes > > > > > > (4) Hold a formal vote on the dev list on two most popular options > > > > > > (5) Make a decision and stick to it > > > > > > Any objections to that? > > > > My view is if it ain't broke, don't fix it - the corolllary is that > > the poll needs to ask for specific reasons why a change would be an > > improvement, not just a popularity contest of the logging systems, > > because that tends to be influenced by what one is used to. > > > > The trouble is enough people out there who think commons-logging is, at > least partially, broken, especially for web apps (option I tend to > share). As far as I know (I may be wrong, though) commons-logging > development seems stagnant and there is little hope of any further > releases. > > Last time we had a pretty unexpected results with the poll on Java 1.5 > compatibility. All I am saying let's discuss our options for the _very_ > last time, and on the user list. In order to have some sort of measure > of what people think on the subject this should be held in a form of a > poll. It does not mean we have to automatically take the option with a > simple majority of votes, but it would be wrong to not take it into > account. > > Oleg > > > > Evil Comrade Oleg > > > > > > > > > > > > - > > > 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HttpClient] Logging wars revisited for the last time (really)
On Fri, 2008-05-23 at 11:09 +0100, sebb wrote: > On 23/05/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > Folks, > > > > We finally need to make a decision on the logging toolkit we are going > > to use in HttpClient 4.0 onwards. > > I agree that the decision needs to be final - but first it has to be static > ;-) > Right you are ;-) > > http://issues.apache.org/jira/browse/HTTPCLIENT-416 > > > > Here's my suggestion about the course of action we should take > > > > (1) I'll start a poll on the user list about popular opinion on the > > matter and propose three alternatives: > > > > * keeping commons-logging > > * migrating to slf4j > > * migrating to j.u.logging > > > > (2) Let the poll run for a week or so and get the users express their > > preferences and opinions. > > > > (3) Tally the votes > > > > (4) Hold a formal vote on the dev list on two most popular options > > > > (5) Make a decision and stick to it > > > > Any objections to that? > > My view is if it ain't broke, don't fix it - the corolllary is that > the poll needs to ask for specific reasons why a change would be an > improvement, not just a popularity contest of the logging systems, > because that tends to be influenced by what one is used to. > The trouble is enough people out there who think commons-logging is, at least partially, broken, especially for web apps (option I tend to share). As far as I know (I may be wrong, though) commons-logging development seems stagnant and there is little hope of any further releases. Last time we had a pretty unexpected results with the poll on Java 1.5 compatibility. All I am saying let's discuss our options for the _very_ last time, and on the user list. In order to have some sort of measure of what people think on the subject this should be held in a form of a poll. It does not mean we have to automatically take the option with a simple majority of votes, but it would be wrong to not take it into account. Oleg > > Evil Comrade Oleg > > > > > > > > - > > 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: [HttpClient] Logging wars revisited for the last time (really)
On 23/05/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > Folks, > > We finally need to make a decision on the logging toolkit we are going > to use in HttpClient 4.0 onwards. I agree that the decision needs to be final - but first it has to be static ;-) > http://issues.apache.org/jira/browse/HTTPCLIENT-416 > > Here's my suggestion about the course of action we should take > > (1) I'll start a poll on the user list about popular opinion on the > matter and propose three alternatives: > > * keeping commons-logging > * migrating to slf4j > * migrating to j.u.logging > > (2) Let the poll run for a week or so and get the users express their > preferences and opinions. > > (3) Tally the votes > > (4) Hold a formal vote on the dev list on two most popular options > > (5) Make a decision and stick to it > > Any objections to that? My view is if it ain't broke, don't fix it - the corolllary is that the poll needs to ask for specific reasons why a change would be an improvement, not just a popularity contest of the logging systems, because that tends to be influenced by what one is used to. > Evil Comrade Oleg > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
