fluffynuts edited a comment on pull request #59: URL: https://github.com/apache/logging-log4net/pull/59#issuecomment-656884829
Hi I'll be honest: friction to getting a PR merged in as a non-Apache dev is really daunting. I keep putting it off, but I'm not sure if I'm ever going to get around to ticking all the boxes, crossing all the T's and dotting all the I's. I feel like a flake, but really, I'm just another human being with a limited number of keystrokes they can make in their lifetime. This, to me, feels like a failing of the process: when the most difficult thing you ask of contributors is to follow some internal processes that, really, _don't matter to the project_. The binaries aren't signed -- what is the point of any of the hullabaloo preceding that? Perhaps it matters for Apache Java stuff, but the pretense of that mattering for log4net was dropped the moment signing was dropped -- and really, I don't mind that signing _was_ dropped: nuget.org provides enough verification of valid binaries, imo. _None of my libraries are signed, and I'm ok with that._ I don't want log4net to die -- I specifically picked this up to keep a useful library going -- but I'm wondering if this is something I can even make a meaningful difference in. I've also really struggled in this process to find definitive direction as to exactly _how_ things should get done. Some say Apache Jenkins is where build & release should happen. Others say external CI (like AppVeyor) is fine, but CircleCI apparently isn't. When I get build pipelines in place to support AppVeyor and (if it were accepted), CircleCI, I read that many releases are done from dev machines -- so why did I spend the many many hours on learning the flows for external CI pipelines & working out the kinks so they actually worked? Log4Net holds a lot of legacy support -- getting that to work in an arbitrary build environment is non-trivial, but, at the end of the day: worth it -- the build I've proposed still gets log4net out to .net 2.0 and CF targets! On AppVeyer! An environment I have _very_ little control over! And using docker! I learned enough docker to be dangerous enough to get build for ancient .net-supporting systems to actually work! I see a couple of courses of action here: 1. Someone convinces me that the steps required to contribute to log4net are not as daunting as I think they are, that I'm just really mistaken about the hurdles I perceive; and I strive ahead. 2. I leave this where it is, and this is just part of the fizzle of log4net dying 3. I fork, because I can, and follow agile principles, performing regular, small releases, as and when it makes sense. I would need to know that anyone actually cares for me to do this before trying as it carries with it the all of the responsibility and at least 1/2 the work involved in (1), but at least I'd have the freedom to automate releases and perform incremental releases at the drop of a hat, as I do with my own libraries. If the world has moved on, so be it, but if the 33 other outstanding PRs against apache-logging/log4net are important to anyone, I need to know before I sink even more hours into this. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
