logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Next release
Date Tue, 15 Jul 2014 11:30:39 GMT
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.brouwer@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.brouwer@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.goers@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 <garydgregory@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 <garydgregory@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 <garydgregory@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.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 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 <boards@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.brouwer@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 <boards@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: garydgregory@gmail.com | ggregory@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

Mime
View raw message