logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Psenner <dpsen...@apache.org>
Subject Re: Response to call to arms
Date Thu, 20 Oct 2016 06:43:44 GMT
It's great to see new faces! Welcome Tommy!

On 2016-10-19 14:20, Tommy Parnell wrote:
> I too added myself to this list from the blog post. I am 
> https://github.com/terribledev <https://github.com/terribledev> I 
> usually have a few days a month to help with these kinds of projects. 
> Been using log4net since 2011. Mostly interested in performance 
> things, and helping on .net core compatibility. That being said always 
> willing to bug fix, and shave some yaks. My bread and butter is 
> in CI/CD (i've built dotnet projects in ruby, node, msbuild only, 
> cake, sake, etc.) so yeah can do that too! I have done quite a bit 
> with shared projects, with compiler directives. Work in Boston, MA USA 
> πŸ‡ΊπŸ‡Έ moved here from the UK πŸ‡¬πŸ‡§. so yeah that's me!
> Oh also, Generics πŸ‘ and linq πŸ‘πŸ‘πŸ‘ Love the ideas! I'll probably 
> grok the codebase for a while, and eventually pick up a jira or two.
> <https://github.com/terribledev>
> TerribleDev (Tommy Parnell) Β· GitHub <https://github.com/terribledev>
> github.com
> TerribleDev has 116 repositories available. Follow their code on GitHub.
> ------------------------------------------------------------------------
> *From:* Dominik Psenner <dpsenner@apache.org>
> *Sent:* Wednesday, October 19, 2016 4:28 AM
> *To:* log4net-dev@logging.apache.org
> *Subject:* Re: Response to call to arms
> Hi Joe,
> good to read you and welcome on the dev list! You're free to work on 
> issues that attract your attention. Nobody's going to force you to 
> work on things you don't deem to be worth the effort.
> We've already decided to gradually drop official support for ancient 
> .net frameworks like .NET 1.X. We are no longer going to actively 
> maintain those targets and if changes to the codebase break those 
> targets we are no longer going to fix that unless someone else 
> provides a patch that restores compatibility. This means that we are 
> shifting the responsibility of maintenance to whoever requires the 
> latest log4net version to work on those ancient platforms.
> Further, compact framework mostly does not support several appenders 
> that for example target the System.Net namespace. Please correct me if 
> I'm wrong, but from memory a prominent example appender is the 
> EmailAppender. I agree with you that it would be a great improvement 
> if we were able to refactor away all those #ifdef's. Unfortunately 
> this wish is very hard to achieve, even impossible if we wanted to 
> stay backwards compatible.
> Backwards compatibility is the next thing I would like to mention. 
> log4net is a logging framework and one of the highest goods is its 
> backwards compatibility. If we are going to break that we must follow 
> a path similar to that of log4j2. In that world the old API facades 
> the log4j2 API and therefore migration of existing code is trivial.
> Cheers and greets,Dominik
> On 2016-10-18 22:42, Joe wrote:
>> I'm responding to Stefan's call-to-arms, though I have limited time 
>> available, currently probably not more than a day or two a month.
>> Given my lack of time I would probably want to get involved in 
>> specific short-term tasks, such as taking on issues from the issue 
>> tracker, rather than being a driver to shape the future of log4net.
>> I have been involved recently in writing a custom asynchronous 
>> appender that logs to a WebAPI, so asynchronous appenders is one area 
>> I could get involved in.
>> One thing I'd personally like to see is to drop support for some 
>> legacy platforms:
>>    - The few .NET 1.x users left are probably adequately served by 
>> existing versions of log4net.
>>    - It's not onerous for .NET 2.0/3.0 users to upgrade to .NET 3.5, 
>> so these could maybe be dropped too (existing apps don’t need to be 
>> rebuilt; they just need to ensure 3.5 is installed).
>>    - I've no experience with Compact Framework, but wonder whether, 
>> given the platform restrictions, it would be better served going 
>> forward by a separate code base with a simplified and restricted 
>> logging framework that exposes an identical API to applications.
>> Doing this would make development easier, for example by allowing the 
>> use of generics and Linq.
>> Which in turn might attract more developers ...
>> One way to approach it would be to remove the binaries for these 
>> platforms from the next release, and only remove from the source code 
>> if a reasonable period elapses without too much wailing and gnashing 
>> of teeth.

View raw message