Return-Path: X-Original-To: apmail-logging-log4j-dev-archive@www.apache.org Delivered-To: apmail-logging-log4j-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 685DA116E6 for ; Mon, 14 Jul 2014 05:46:03 +0000 (UTC) Received: (qmail 82584 invoked by uid 500); 14 Jul 2014 05:46:03 -0000 Delivered-To: apmail-logging-log4j-dev-archive@logging.apache.org Received: (qmail 82533 invoked by uid 500); 14 Jul 2014 05:46:03 -0000 Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@logging.apache.org Received: (qmail 82515 invoked by uid 99); 14 Jul 2014 05:46:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Jul 2014 05:46:03 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_REMOTE_IMAGE X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of boards@gmail.com designates 209.85.214.176 as permitted sender) Received: from [209.85.214.176] (HELO mail-ob0-f176.google.com) (209.85.214.176) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Jul 2014 05:45:59 +0000 Received: by mail-ob0-f176.google.com with SMTP id wo20so3652367obc.21 for ; Sun, 13 Jul 2014 22:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JEArENBxpWuFLcFzF/oWPjtfBzOr48i5tLH98hayvyc=; b=ktg51BW5KmzkozyE7JtJbo03GQvklVOl9Tm6k0qLynfYkYT2yBp36ue1ffC3b64ori J4Bf/oHnQmhhldbg5CV6ieMSnp4FW0NqAqydZ12qzcxIxFGlC2wWqsX4gzdS1VsO/TKj mD00hx8ZyFY5qMnXsfWBHnx1tRJTJ/QEIGSYGrwc+oYkILV25j+2Xe+Obvi7b50u4b/6 FpYDhzB9Yo63Q3VeEPOlnxNDDcJEFnB+T9QPT54v69X7tUK6fFawAMfNwBUwtJnjcWiS jZ8WFgQWf5RxJC9LzMlA64JJYVyko2ImETfrXDzl8utLNfVCefroICemgK+3xjVNVfhB 8KCQ== MIME-Version: 1.0 X-Received: by 10.60.133.233 with SMTP id pf9mr15650435oeb.30.1405316738427; Sun, 13 Jul 2014 22:45:38 -0700 (PDT) Received: by 10.76.128.177 with HTTP; Sun, 13 Jul 2014 22:45:38 -0700 (PDT) In-Reply-To: <9BFE3FD9-76AF-4514-A61F-48284A840BEF@apache.org> References: <0tc6njr7ik8jmfaal6ukk865.1405308496093@email.android.com> <9BFE3FD9-76AF-4514-A61F-48284A840BEF@apache.org> Date: Mon, 14 Jul 2014 00:45:38 -0500 Message-ID: Subject: Re: Next release From: Matt Sicker To: Log4J Developers List Cc: Logging PMC Content-Type: multipart/alternative; boundary=047d7b472078fdb02c04fe20ccda X-Virus-Checked: Checked by ClamAV on apache.org --047d7b472078fdb02c04fe20ccda Content-Type: text/plain; charset=UTF-8 I, too, would prefer to release now and follow up with updates in the short term. On 13 July 2014 23:35, Ralph Goers wrote: > I guess that means you won't be voting on the current release candidate? > Pretty much everyone else thinks it is time. If that is the case one of the > other PMC members will need to fail or the release vote will fail. > > For what it is worth, I have no problem with a 2.0.1 or 2.1 in a few weeks > if desired. I just think we have been stalling long enough. > > And I hope we continue to keep fixing things at the same, or better, pace. > > Sent from my iPad > > On Jul 13, 2014, at 8:28 PM, Gary Gregory wrote: > > I'd be ok with another RC. My ideal scenario is that an RC is released, > some time goes by without new bug reports and then the next RC becomes a > release. As things are now, we've fixed plenty since rc2. But hey that's > just me ;-) > > Gary > > > -------- Original message -------- > From: Bruce Brouwer > Date:07/13/2014 22:35 (GMT-05:00) > To: Log4J Developers List > Subject: Re: Next release > > Ok, the only test that didn't pass was the one testing for StatusLogger > writing to a file. I removed that test on the branch. If you review that > and think it worthy to go into the trunk, I'm pretty much on board with a > 2.0 release (unless you think a short lived rc3 is in order). > > > On Sun, Jul 13, 2014 at 9:29 PM, Bruce Brouwer > wrote: > >> Ok, this is starting to be simpler, as I'm sure you would all prefer. You >> can look at the branch LOG4J-609 again if you like. Here are the >> simplifications that I have made. >> >> 1) The listeners no longer report their level. They can decide if they >> want to do something with a status message in their log method. >> 2) There is no longer the option to configure the StatusLogger to write >> to a file. >> 3) I moved StatusConsoleListener out of log4j-api and into log4j-core, >> where we can probably get away with making more drastic changes to it in >> the future (so I can fix LOG4J-609) >> >> I have to check on the tests and stuff, but in general, I'm pretty happy >> with how small the impact is and in its ability to make a better solution >> for LOG4J-609 possible in the future. >> >> >> On Sun, Jul 13, 2014 at 8:23 PM, Matt Sicker wrote: >> >>> This actually makes me wonder why you can configure the status logger >>> from a configuration file. Shouldn't this just be a system property or >>> something? >>> >>> >>> On 13 July 2014 18:57, Bruce Brouwer wrote: >>> >>>> The listener can be removed, but nothing ever does. Right now it can >>>> never know if it should be removed. And also, all that level checking is >>>> cached in StatusLogger. If all you do is change the status level of the >>>> listener it has no effect on the cached value in StatusLogger. It may end >>>> up having no effect. >>>> >>>> This is some of the stuff I was trying to clean up with my fix that I >>>> have been delinquent with. >>>> >>>> I will try to simplify this on the branch and see if it makes sense in >>>> the next hour or two. >>>> >>> >>> >>> >>> -- >>> Matt Sicker >>> >> >> >> >> -- >> >> >> Bruce Brouwer >> about.me/bruce.brouwer >> [image: Bruce Brouwer on about.me] >> >> > > > > -- > > > Bruce Brouwer > about.me/bruce.brouwer > [image: Bruce Brouwer on about.me] > > > -- Matt Sicker --047d7b472078fdb02c04fe20ccda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I, too, would prefer to release now and follow up with upd= ates in the short term.


On 13 July 2014 23:35, Ralph Goers &l= t;rgoers@apache.org<= /a>> wrote:
I guess that means yo= u won't be voting on the current release candidate? Pretty much everyon= e else thinks it is time. If that is the case one of the other PMC members = will need to fail or the release vote will fail.

For what it is worth, I have no problem with a 2.0.1 or= 2.1 in a few weeks if desired. =C2=A0I just think we have been stalling lo= ng enough.

And I hope we continue to keep fixing t= hings at the same, or better, pace.

Sent from my iPad
I'd be ok with another RC. My ideal scenario is that an RC is rele= ased, some time goes by without new bug reports and then the next RC become= s a release. As things are now, we've fixed plenty since rc2. But hey t= hat's just me ;-)

Gary


-------- Original message --------
From: Bruce Brouwer
Date:07/13/2014 22:3= 5 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Next release

Ok, th= e only test that didn't pass was the one testing for StatusLogger writi= ng to a file. I removed that test on the branch. If you review that and thi= nk it worthy to go into the trunk, I'm pretty much on board with a 2.0 = release (unless you think a short lived rc3 is in order).=C2=A0


On Sun, Jul 1= 3, 2014 at 9:29 PM, Bruce Brouwer <bruce.brouwer@gmail.com> wrote:
Ok, this is starting to be = simpler, as I'm sure you would all prefer. You can look at the branch L= OG4J-609 again if you like. Here are the simplifications that I have made.<= div>
1) The listeners no longer report their level. They can deci= de if they want to do something with a status message in their log method.= =C2=A0
2) There is no longer the option to configure the StatusLogger to writ= e to a file.=C2=A0
3) I moved StatusConsoleListener out of log4j-= api and into log4j-core, where we can probably get away with making more dr= astic changes to it in the future (so I can fix LOG4J-609)

I have to check on the tests and stuff, but in general,= I'm pretty happy with how small the impact is and in its ability to ma= ke a better solution for LOG4J-609 possible in the future.=C2=A0


On = Sun, Jul 13, 2014 at 8:23 PM, Matt Sicker <boards@gmail.com> = wrote:
This actually makes me wonder why you can configure the st= atus logger from a configuration file. Shouldn't this just be a system = property or something?


On 13 July 2014 18:57, Bruce Brouwer <bruce.brouwer@gmail.com>= ; wrote:

The listener can be removed, but nothing ever does. Right no= w it can never know if it should be removed. And also, all that level check= ing is cached in StatusLogger. If all you do is change the status level of = the listener it has no effect on the cached value in StatusLogger. It may e= nd up having no effect.

This is some of the stuff I was trying to clean up with my f= ix that I have been delinquent with.

I will try to simplify this on the branch and see if it make= s sense in the next hour or two.




--
Matt Sicker <boards@gmail.com>






--



--
Matt Sicker <boards@gmail.com> --047d7b472078fdb02c04fe20ccda--