Re: Response to call to arms
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 <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.
Re: Response to call to arms
You've got the point. Obviously this all greatly depends what needs to get done. Let me outline this with an example: Requirement: we want log4net to have an API where users must not invoke IsLogLevelEnabled to check if a log level is enabled and we want to have this without changing the current public API of the ILog interface Implementation: we are going to implement this with lambdas Implementation dependencies: this in turn requires us to target at least net 3.5 and above The outcome of this example is the log4net.Utils.ILogExtensions static class. Cheers, Dominik On 2016-10-19 20:02, Joe wrote: Thanks for the response. I don’t think there’s any rush to remove the ifdefs for obsolete platforms ; the important thing is to know we don’t need to add them for new code. As a minor example I recently contributed code which measured elapsed time using DateTime.UtcNow: I’d probably have used a Stopwatch had I known .NET 1.x support was not required. By implication you are planning to continue to target .NET 2.0 so presumably the rules are: -Avoid using features from .NET 3.5+ in core components -It’s OK to depend on .NET 3.5 for new loosely-coupled components such as Appenders – in this case the whole file just needs to be included in an #ifdef I’ll start off by looking at LOGNET-407 as suggested by Stefan. *From:*Dominik Psenner [mailto:dpsen...@apache.org] *Sent:* 19 October 2016 10:29 *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.
RE: Response to call to arms
Thanks for the response. I don't think there's any rush to remove the ifdefs for obsolete platforms ; the important thing is to know we don't need to add them for new code. As a minor example I recently contributed code which measured elapsed time using DateTime.UtcNow: I'd probably have used a Stopwatch had I known .NET 1.x support was not required. By implication you are planning to continue to target .NET 2.0 so presumably the rules are: - Avoid using features from .NET 3.5+ in core components - It's OK to depend on .NET 3.5 for new loosely-coupled components such as Appenders - in this case the whole file just needs to be included in an #ifdef I'll start off by looking at LOGNET-407 as suggested by Stefan. From: Dominik Psenner [mailto:dpsen...@apache.org] Sent: 19 October 2016 10:29 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.
Re: Response to call to arms
Welcome Tommy I'm sure we can use your expertise if we'd want to handle our platform zoo in an easier way :-) Also, since you mention .NET Core. I've created some test builds[1] as precursor for the next release - this was before we started to merge Joe's pull requests. AFAIK nobody has verified the .NET Core version actually works the way it is supposed to. And we might need some docs about using and configuring log4net on .NET Core. That being said, once you raise your hand you'll probably get asked to do more. So don't allow us to push you into directions you don't want to go :-) Stefan [1] http://stefan.samaflost.de/staging/log4net-2.0.6/ On 2016-10-19, Tommy Parnell wrote: > 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=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
Re: Response to call to arms
On 2016-10-18, 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. Which may be more than Dominik and I have spent in some month. Welcome! > 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. Whatever suits you best. > 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. If you'd find some time to look into https://issues.apache.org/jira/browse/LOG4NET-407 that would be great. The code even made it into the 1.3.x branch before we abandoned that, it may need to get tweaked so the build system of trunk works. > One thing I'd personally like to see is to drop support for some > legacy platforms: What Dominik said. I'm not even sure the current code base builds on 1.x. I've got a VM that builds 2.0 (by cheating and using 3.5 targeting 2.0) up to 4.5 (also cheating, unless I'm mistaken I'm using 4.6.x by now to build the 4.x releases). > 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. We've already announced the next release wouldn't contain binaries for the compact framework and 1.x builds - I no longer have any of those installed anymore as running a Win XP VM and keeping it away from a public network simply isn't anything I want to do anymore. Stefan
