RE: Apache log4net Needs Help

[Joe <Jo...@hotmail.com>]

> If you are willing to help, please join log4net's dev mailing list and raise your hand. Look through log4net's issue tracker and pick things you'd like to work on. If you don't know where to start, please ask, Dominik and Stefan will be there to help.

> If there is anything holding you back from contributing, let's discuss it and get it out of the way. 

Looking through the log4net issue tracker, I find it difficult to pick out things to work on.

- There are an awful lot of open issues that have been open for a long time and are unassigned
- Some of the ones I've looked through seem like they could be closed as Won't fix, Incomplete, Cannot Reproduce, Later or Not a Bug.  Doing this might show that things are moving and be an incentive for people to get involved.  
- It would help to have a roadmap for the next couple of releases.   For example, if we know that someone is working on a revamped RollingFileAppender, all issues related to RollingFileAppender should be assigned to them.
- Perhaps some of them need to be reprioritized, so that it's easier to focus on what is high priority and consistent with the roadmap.

RE: Apache log4net Needs Help

[Dominik Psenner <dp...@gmail.com>]

This sounds like a plan.

On 6 Nov 2016 8:25 p.m., "Joe" <Jo...@hotmail.com> wrote:

> > A long time ago I had started a reimplementation of the
> RollingFileAppender because we've seen that we cannot fix it without
> breaking compatibility or redefining its features. Most of the
>
> > issues related to the RollingFileAppender should be marked as related
> issues to the rewrite issue. I dont have the issue id at hand, though. If
> you wanted to pick up that initial work and
>
> > continue it would be awesome! Most probably I am going to jump in
> helping you because the RollingFileAppender is one of the most used
> features and therefore one of the crucial points
>
> > where performance and sanity can make a difference of users moving away
> from log4net or attracting more users.
>
>
>
> I’d be willing to get involved in that.  A suggestion for what I could do
> over the next months:
>
>
>
> 1.  Complete AsyncAppenderSkeleton and AsyncForwardingAppender
>
>
>
> 2. Possibly implement the ability to log to an ILog from an appender
> derived from AsyncAppenderSkeleton if the re-entrancy issues can be solved
> (which I think they can).
>
>
>
> 3. Implement performance counters in AsyncAppenderSkeleton (and maybe
> AppenderSkeleton).  I’ve recently done something similar for a custom
> asynchronous appender, and it should be fairly straightforward to
> implement.  The idea is to make it easy to monitor performance of an
> appender: number of logging events processed, rate at which they’re
> processed, average processing time, queue length when in asynchronous mode,
> …  I’ll create an issue for this in due course with a more detailed
> description.
>
>
>
> 4. Reimplement RollingFileAppender, perhaps as AsyncRollingFileAppender
> derived from AsyncAppenderSkeleton.  It might be useful to be able to use
> it in asynchronous mode, for example to reduce the performance impact of
> contention for the mutex when logging to a shared file.
>
>
>
>
>

RE: Apache log4net Needs Help

[Joe <Jo...@hotmail.com>]

> A long time ago I had started a reimplementation of the RollingFileAppender because we've seen that we cannot fix it without breaking compatibility or redefining its features. Most of the
> issues related to the RollingFileAppender should be marked as related issues to the rewrite issue. I dont have the issue id at hand, though. If you wanted to pick up that initial work and
> continue it would be awesome! Most probably I am going to jump in helping you because the RollingFileAppender is one of the most used features and therefore one of the crucial points
> where performance and sanity can make a difference of users moving away from log4net or attracting more users.

I’d be willing to get involved in that.  A suggestion for what I could do over the next months:

1.  Complete AsyncAppenderSkeleton and AsyncForwardingAppender

2. Possibly implement the ability to log to an ILog from an appender derived from AsyncAppenderSkeleton if the re-entrancy issues can be solved (which I think they can).

3. Implement performance counters in AsyncAppenderSkeleton (and maybe AppenderSkeleton).  I’ve recently done something similar for a custom asynchronous appender, and it should be fairly straightforward to implement.  The idea is to make it easy to monitor performance of an appender: number of logging events processed, rate at which they’re processed, average processing time, queue length when in asynchronous mode, …  I’ll create an issue for this in due course with a more detailed description.

4. Reimplement RollingFileAppender, perhaps as AsyncRollingFileAppender derived from AsyncAppenderSkeleton.  It might be useful to be able to use it in asynchronous mode, for example to reduce the performance impact of contention for the mutex when logging to a shared file.

Re: Apache log4net Needs Help

[Dominik Psenner <dp...@gmail.com>]

2016-11-05 19:38 GMT+01:00 Stefan Bodewig <bo...@apache.org>:

> On 2016-11-05, Joe wrote:
>
> >> If you are willing to help, please join log4net's dev mailing list and
> raise your hand. Look through log4net's issue tracker and pick things you'd
> like to work on. If you don't know where to start, please ask, Dominik and
> Stefan will be there to help.
>
> >> If there is anything holding you back from contributing, let's discuss
> it and get it out of the way.
>
> > Looking through the log4net issue tracker, I find it difficult to pick
> > out things to work on.
>
> > - There are an awful lot of open issues that have been open for a long
> > time and are unassigned
>
> I've gone through them a long time ago when it looked like we had a plan
> of moving forward - that's why you may find some issues assigned to
> versions like 3.5 or 4. Reality has rendered those versions moot.
>
> > - Some of the ones I've looked through seem like they could be closed
> > as Won't fix, Incomplete, Cannot Reproduce, Later or Not a Bug.  Doing
> > this might show that things are moving and be an incentive for people
> > to get involved.
>
> Fine with me. So far I haven't closed any enhancement requests as I
> thought somebody might pick it up. But at the same time I knew I
> wouldn't be working on it. I've tried to keep up with real bug reports
> and enhancement requests that came with a path - but likely failed to do
> so as well.
>
> > - It would help to have a roadmap for the next couple of releases.
> > For example, if we know that someone is working on a revamped
> > RollingFileAppender, all issues related to RollingFileAppender should
> > be assigned to them.
>
> The main reason we've lacked a roadmap so far is that we've been
> reacting to reported bugs. I'd be happy if we could change this. Short
> term I'd love to see us release 2.0.6 as a sign of life.
>

A long time ago I had started a reimplementation of the RollingFileAppender
because we've seen that we cannot fix it without breaking compatibility or
redefining its features. Most of the issues related to the
RollingFileAppender should be marked as related issues to the rewrite
issue. I dont have the issue id at hand, though. If you wanted to pick up
that initial work and continue it would be awesome! Most probably I am
going to jump in helping you because the RollingFileAppender is one of the
most used features and therefore one of the crucial points where
performance and sanity can make a difference of users moving away from
log4net or attracting more users.


>
> > - Perhaps some of them need to be reprioritized, so that it's easier
> > to focus on what is high priority and consistent with the roadmap.
>
> Current priorities are most likely the ones set by the reporters. Which
> usually means everybody considers their issues the most important ones.
>

I tend to prioritize recent reports because the reporters of those old
issues most likely have found a workaround or moved to another logging
framework. Those issues are most likely to be closed because they are not
reproducable.

-- 
Dominik Psenner

Re: Apache log4net Needs Help

[Dominik Psenner <dp...@gmail.com>]

2016-11-05 19:38 GMT+01:00 Stefan Bodewig <bo...@apache.org>:

> On 2016-11-05, Joe wrote:
>
> >> If you are willing to help, please join log4net's dev mailing list and
> raise your hand. Look through log4net's issue tracker and pick things you'd
> like to work on. If you don't know where to start, please ask, Dominik and
> Stefan will be there to help.
>
> >> If there is anything holding you back from contributing, let's discuss
> it and get it out of the way.
>
> > Looking through the log4net issue tracker, I find it difficult to pick
> > out things to work on.
>
> > - There are an awful lot of open issues that have been open for a long
> > time and are unassigned
>
> I've gone through them a long time ago when it looked like we had a plan
> of moving forward - that's why you may find some issues assigned to
> versions like 3.5 or 4. Reality has rendered those versions moot.
>
> > - Some of the ones I've looked through seem like they could be closed
> > as Won't fix, Incomplete, Cannot Reproduce, Later or Not a Bug.  Doing
> > this might show that things are moving and be an incentive for people
> > to get involved.
>
> Fine with me. So far I haven't closed any enhancement requests as I
> thought somebody might pick it up. But at the same time I knew I
> wouldn't be working on it. I've tried to keep up with real bug reports
> and enhancement requests that came with a path - but likely failed to do
> so as well.
>
> > - It would help to have a roadmap for the next couple of releases.
> > For example, if we know that someone is working on a revamped
> > RollingFileAppender, all issues related to RollingFileAppender should
> > be assigned to them.
>
> The main reason we've lacked a roadmap so far is that we've been
> reacting to reported bugs. I'd be happy if we could change this. Short
> term I'd love to see us release 2.0.6 as a sign of life.
>

A long time ago I had started a reimplementation of the RollingFileAppender
because we've seen that we cannot fix it without breaking compatibility or
redefining its features. Most of the issues related to the
RollingFileAppender should be marked as related issues to the rewrite
issue. I dont have the issue id at hand, though. If you wanted to pick up
that initial work and continue it would be awesome! Most probably I am
going to jump in helping you because the RollingFileAppender is one of the
most used features and therefore one of the crucial points where
performance and sanity can make a difference of users moving away from
log4net or attracting more users.


>
> > - Perhaps some of them need to be reprioritized, so that it's easier
> > to focus on what is high priority and consistent with the roadmap.
>
> Current priorities are most likely the ones set by the reporters. Which
> usually means everybody considers their issues the most important ones.
>

I tend to prioritize recent reports because the reporters of those old
issues most likely have found a workaround or moved to another logging
framework. Those issues are most likely to be closed because they are not
reproducable.

-- 
Dominik Psenner

Re: Apache log4net Needs Help

[Stefan Bodewig <bo...@apache.org>]

On 2016-11-05, Joe wrote:

>> If you are willing to help, please join log4net's dev mailing list and raise your hand. Look through log4net's issue tracker and pick things you'd like to work on. If you don't know where to start, please ask, Dominik and Stefan will be there to help.

>> If there is anything holding you back from contributing, let's discuss it and get it out of the way.

> Looking through the log4net issue tracker, I find it difficult to pick
> out things to work on.

> - There are an awful lot of open issues that have been open for a long
> time and are unassigned

I've gone through them a long time ago when it looked like we had a plan
of moving forward - that's why you may find some issues assigned to
versions like 3.5 or 4. Reality has rendered those versions moot.

> - Some of the ones I've looked through seem like they could be closed
> as Won't fix, Incomplete, Cannot Reproduce, Later or Not a Bug.  Doing
> this might show that things are moving and be an incentive for people
> to get involved.

Fine with me. So far I haven't closed any enhancement requests as I
thought somebody might pick it up. But at the same time I knew I
wouldn't be working on it. I've tried to keep up with real bug reports
and enhancement requests that came with a path - but likely failed to do
so as well.

> - It would help to have a roadmap for the next couple of releases.
> For example, if we know that someone is working on a revamped
> RollingFileAppender, all issues related to RollingFileAppender should
> be assigned to them.

The main reason we've lacked a roadmap so far is that we've been
reacting to reported bugs. I'd be happy if we could change this. Short
term I'd love to see us release 2.0.6 as a sign of life.

> - Perhaps some of them need to be reprioritized, so that it's easier
> to focus on what is high priority and consistent with the roadmap.

Current priorities are most likely the ones set by the reporters. Which
usually means everybody considers their issues the most important ones.

Stefan

Re: Apache log4net Needs Help

[Stefan Bodewig <bo...@apache.org>]

On 2016-11-05, Joe wrote:

>> If you are willing to help, please join log4net's dev mailing list and raise your hand. Look through log4net's issue tracker and pick things you'd like to work on. If you don't know where to start, please ask, Dominik and Stefan will be there to help.

>> If there is anything holding you back from contributing, let's discuss it and get it out of the way.

> Looking through the log4net issue tracker, I find it difficult to pick
> out things to work on.

> - There are an awful lot of open issues that have been open for a long
> time and are unassigned

I've gone through them a long time ago when it looked like we had a plan
of moving forward - that's why you may find some issues assigned to
versions like 3.5 or 4. Reality has rendered those versions moot.

> - Some of the ones I've looked through seem like they could be closed
> as Won't fix, Incomplete, Cannot Reproduce, Later or Not a Bug.  Doing
> this might show that things are moving and be an incentive for people
> to get involved.

Fine with me. So far I haven't closed any enhancement requests as I
thought somebody might pick it up. But at the same time I knew I
wouldn't be working on it. I've tried to keep up with real bug reports
and enhancement requests that came with a path - but likely failed to do
so as well.

> - It would help to have a roadmap for the next couple of releases.
> For example, if we know that someone is working on a revamped
> RollingFileAppender, all issues related to RollingFileAppender should
> be assigned to them.

The main reason we've lacked a roadmap so far is that we've been
reacting to reported bugs. I'd be happy if we could change this. Short
term I'd love to see us release 2.0.6 as a sign of life.

> - Perhaps some of them need to be reprioritized, so that it's easier
> to focus on what is high priority and consistent with the roadmap.

Current priorities are most likely the ones set by the reporters. Which
usually means everybody considers their issues the most important ones.

Stefan