Easy for me to say 'do another RC' since I am not the RM but there is no harm in doing a RC3, if anything it shows we are getting our ducks in a row before GA. My experience RM'ing for Commons, HttpComponents and Xalan is that it is a pain in the you know what, so I won't hold it against Ralph if he is tried of cutting releases ;-)
Gary On Tue, Jul 15, 2014 at 7:17 AM, Bruce Brouwer <bruce.brou...@gmail.com> wrote: > I am thinking I will commit my changes for 609 to the trunk tonight > (unless i hear otherwise) to get it included in 2.0. The impact to -api is > pretty small so I will leave it to you to decide if we need an rc3. My vote > is we do. With this change I consider 609 to be resolved. > On Jul 14, 2014 5:42 PM, "Bruce Brouwer" <bruce.brou...@gmail.com> wrote: > >> In the latest stuff in my branch, the biggest change in api is >> StatusConsoleListener moved to -core >> On Jul 14, 2014 1:23 PM, "Ralph Goers" <ralph.go...@dslextreme.com> >> wrote: >> >>> StatusLogger is public in the sense that user written components will >>> use it. But all we really expose to components there is the >>> StatusLogger.getLogger() and the Logger interface. The other public methods >>> there are for JMX and the configuration to access the status data. Nothing >>> else under the status package is really public. >>> >>> I haven’t looked at Bruce’s changes yet but I can’t imagine how they >>> would result in API breakage. >>> >>> Ralph >>> >>> >>> >>> On Jul 14, 2014, at 10:04 AM, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> >>> If we break binary compatibility then we should change the package name. >>> This is to avoid well know jar hell issues. What we need to decide is which >>> APIs are really public. For example in Commons, all public APIs are part of >>> the binary compatibility agreement we've made. We now have lang3, pool2, >>> dbcp2, for example. Looking ahead to not breaking binary compatibility is >>> why I think we need to be sure we agree now on what the public API is. >>> >>> Gary >>> >>> >>> -------- Original message -------- >>> From: Remko Popma >>> Date:07/14/2014 12:43 (GMT-05:00) >>> To: Log4J Developers List >>> Subject: Re: Next release >>> >>> Bruce, I've done an initial review of the LOG4J2-609 branch and posted >>> some comments in the Jira. >>> >>> Gary, I'm not in principle against changes to the API module in post-2.0 >>> releases. Changes need to have enough merit to justify them, but if they >>> do, then making these changes before or after 2.0 doesn't matter that much >>> to me. We've been in beta so long that I'm sure we have quite a few users >>> already, so to me we are live already. >>> >>> I do appreciate you want it to be as close to perfect as we can make it. >>> But I also agree with the others that releasing a GA version now won't >>> prevent us from making further improvements. >>> >>> By the way, when I told some people at work that we're close to the 2.0 >>> release, their first impression was: "finally!" :-) >>> >>> >>> On Mon, Jul 14, 2014 at 9:32 PM, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> >>>> I'll give the VOTE a review of course but I do not see the harm in >>>> another RC since we will be setting the API in stone as soon as 2.0 is out. >>>> We also have only one shot at a first impression. >>>> >>>> Gary >>>> >>>> >>>> -------- Original message -------- >>>> From: Ralph Goers >>>> Date:07/14/2014 00:35 (GMT-05:00) >>>> To: Log4J Developers List >>>> Cc: Logging PMC >>>> Subject: Re: Next release >>>> >>>> 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 <garydgreg...@gmail.com> >>>> 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 <bruce.brou...@gmail.com >>>> > 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 <boa...@gmail.com> 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 <bruce.brou...@gmail.com> 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 <boa...@gmail.com> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> Bruce Brouwer >>>>> about.me/bruce.brouwer >>>>> [image: Bruce Brouwer on about.me] >>>>> <http://about.me/bruce.brouwer> >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> Bruce Brouwer >>>> about.me/bruce.brouwer >>>> [image: Bruce Brouwer on about.me] >>>> <http://about.me/bruce.brouwer> >>>> >>>> >>> >>> -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
