I too added myself to this list from the blog post. I am 
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://avatars2.githubusercontent.com/u/3459800?v=3&s=400]<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 <dpsen...@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.


Reply via email to