Hi all I'm new to this list, been using log4net for around 9 years, and only this week discovered that it is being made dormant (and what that means).
I've been told that the team has been looking for outside help for around 2 years, with no-one forthcoming. Unfortunately, as I say, this is the first I've heard of it. I'd like to keep log4net alive because it's used ubiquitously and I think it's a valuable project. I publish my own nuget packages (https://www.nuget.org/profiles/davydm) though obviously, not with the same methodologies of the existing log4net infrastructure. I see that there's a 2.0.9 release that could potentially happen (as per the source), whilst 2.0.8 is still the current release, so I'm assuming there's something holding that up. I also see 34 pull requests on GitHub which are in different states of activity, but many have been dormant since 2018. I'd like to help, but I'm not sure where to start with the log4net infra (I hear there's Jira (I've had little experience) and Jenkins (I've had reasonable experience, but not with pipelines)). I'm not even sure what the state of play is for that infra. I'm sure there are good reasons for making the project dormant -- some of those may include the desire to free up infra which could be used elsewhere (or just not paid for). As I say, I'd like to keep log4net alive. I see a few options here: 1. I learn your infra and your processes. I integrate and try to keep things pretty-much as they were (though I'm sure some things would have to change -- all things do). I don't mind spending the time learning the domain, if that's agreeable to everyone and the project retains it's original branding and status. One thing I'm concerned about here is the dormant backlog 2. As above, with a bit of a clean-slate philosophy: I'd like to remove all backlog items that aren't critical and start with the least outstanding stuff possible. If a report is important, it will be reported again. Trying to trace down the authors and origins of 2+year-old reports is going to be frustrating. Issues which aren't attended to just become noise in the backlog, imo. 3. I fork and perform the "clean slate" approach of above, inviting others to use my variant and log issues there. Uptake will naturally be slow (if even noticeable), which will give me time to deal with incoming issues. On the other hand, I'd have full control and no need to bother anyone else. I would have to come up with a new name and make it clear that it's a fork, though also make it clear I'd be standing on the shoulders of giants. Personally, I'd like (1) because it keeps the project that people rely on alive. Since I'm new to the mailing list, I can't discern yet the sentiment towards the project, except that everyone was quite happy to have it made dormant, so it feels like there's not a lot of desire to keep it going -- which is ok: everything comes to an end at some point, and, as stated earlier, I'm sure there are good reasons for making log4net dormant. As a consumer of log4net, I'd much rather not have to switch over to another framework once there's an issue which affects me more than my logged one (inability to flush logs -- it was on a proof-of-concept project, so it isn't _that_ important to have the functionality right now). Apologies for the rambling message. I was prompted to reach out by Ralph Goers in the discussion for LOG4NET-606, so I hope I haven't been a bother. -d -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- If you say that getting the money is the most important thing You will spend your life completely wasting your time You will be doing things you don't like doing In order to go on living That is, to go on doing things you don't like doing Which is stupid. - Alan Watts https://www.youtube.com/watch?v=-gXTZM_uPMY *Quidquid latine dictum sit, altum sonatur. *
