Great to see log4net gains some momentum! If changing the build system is on the table, I would try sticking with the default msbuild capabilities. Especially useful is the MSBuild inline task capability [1].
[1] https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-inline-tasks?view=vs-2019 On Wed, 8 Apr 2020 at 08:56, Davyd McColl <dav...@gmail.com> wrote: > On progress reports: sure, I'll try to keep this list updated > On PRs: I'm happy to start helping once I've spent more time in the > codebase (which I will have to do anyway), so that I can give better > feedback. > > -d > On 2020-04-08 08:53:44, Ralph Goers <ralph.go...@dslextreme.com> wrote: > Sounds good. If you wouldn’t mind, it would be nice if you could provide > progress reports on a regular schedule that works for you just so we know > you are still working on it. > > Also, as you probably know we do get PRs and questions from time to time > that none of us are comfortable answering. It would be great if you, or one > of the others who has expressed an interest in Log4Net, could respond to > them. > > Ralph > > > On Apr 7, 2020, at 11:18 PM, Davyd McColl wrote: > > > > Thanks Matt > > > > To clarify my plans, I will: > > 1. update the build system for log4net: I haven't seen any objection to > using node-based build scripts as I have for my own packages, so I'll head > down that path. Currently, I use those as a git submodule, but I'm quite > close to having them available as an npm package, so I'll complete that > first, test on my own code and, once I'm happy, use that in log4net, unless > there are any objections. I've generally found that, as powerful as git > submodules are, they cause confusion as a lot of people don't seem to > understand how they work, which is the reason I'm converting my gulp-tasks > repo to an npm package which can just be installed and run. > > > > I'm happy to use whatever works and everyone is comfortable with -- > personally, I'm quite comfortable with the infrastructure my scripts > provide and they're used by my current and previous employer for build, so > they get worked out multiple times per day. > > > > 2. I think that the suggestion to use Docker is a good one, as it would > mean that I don't have to place any burden on someone to ensure that build > dependencies are available at Jenkins. My Docker-fu is, however, feeble, so > I'm going to skill that up. Alternatively, if people are motivated to get a > release out sooner, setting up Docker can be delayed if the following > dependencies are available at the build host: > > - node (preferably the current lts, 12, but 8+ should work) > > - dotnet core sdk 3.1 > > - .Net Framework 4.6.2 or higher (if a windows host) or Mono 5 (Linux / > OSX host) > > In lieu of any communications to the contrary, I'll assume that getting > dependencies onto the build server is a less-desirable / impossible > outcome, so I'll be chasing the Docker route. > > > > 3. When 1 & 2 are ready, I will raise a PR against the log4net GitHub > repo. > > > > I expect this might take a little while, so please bear with me. > > > > -d > > > > On 2020-04-07 17:48:50, Matt Sicker wrote: > > Speaking of the Jenkins build, if you want to use Docker images to > > create a build environment, that's also supported. > > > > On Tue, 7 Apr 2020 at 10:46, Ralph Goers wrote: > >> > >> You should feel free to change the build system in any way that makes > it easier for people to perform a release. Ideally, it would be nice if it > was something that could be automated from Jenkins, but that is not a > requirement. > >> > >> Ralph > >> > >>> On Apr 7, 2020, at 8:42 AM, Davyd McColl wrote: > >>> > >>> Ok, so would it be acceptable to change the build system altogether? > Should I create a PR using the build system (npm / node-based) that I use > for my projects? I'm happy to do so. > >>> > >>> -d > >>> On 2020-04-07 17:39:31, Matt Sicker wrote: > >>> We mostly develop on the JVM which has a fairly different build > >>> system. Performing a release for the .net code seems to involve > >>> multiple build tools, and our old CI setup for log4net is broken due > >>> to nant no longer being included in our Jenkins nodes. Basically, the > >>> only realistic release we can validate is a signed and checksummed > >>> source archive. We need some .net developers to help create the binary > >>> artifacts and verify they're good to distribute. We can help with the > >>> logistics of distributing a copy of your public GPG key for signing > >>> the artifacts, and we can handle committing the release artifacts to > >>> the release repository. We'd also likely invite anyone who does such a > >>> release to join the PMC so that they'd have the proper authorization > >>> to perform all the release steps on their own (other than the vote > >>> itself which we would all take part in). > >>> > >>> On Tue, 7 Apr 2020 at 09:18, Davyd McColl wrote: > >>>> > >>>> I'm glad to help -- not sure where though: > >>>> > >>>> I'm sure I could build (haven't actually done it) log4net and the > associated package, and I could push that to nuget from my own machine, > assuming that I had the credentials to do so. Releasing my own packages is > the least work I have to do when I make changes -- I've automated into an > npm script in NExpect and the PeanutButter packages, where that script > builds, tests, increments package version, packs, pushes, tags and pushes > the commit containing updated .nuspecs and the tag to github. > >>>> > >>>> I'm assuming there's something vastly different here? Are packages > pushed by a CI server (eg the mentioned Jenkins?). Or is the problem simply > that no-one actually knows where the build, sign and push steps are > performed? I assume that the .snk in this solution is the one used to sign > the package (though I would not have expected to find the snk there, > because it allows anyone to sign a package as official). > >>>> > >>>> Does anyone have any idea where to start looking? I see build is done > with Nant (I'm not familiar, but I can probably figure it out) -- other > than that, what do we know about the process? If someone knows (or guesses) > that it's happening at Jenkins, is there a way for me to assist with > debugging that process? > >>>> > >>>> -d > >>>> On 2020-04-07 16:08:06, Apache wrote: > >>>> What you are seeing is exactly what I have been saying. The major > problem is that none of the existing logging services committers know how > to perform a release. We know there have been fixes committed that are > needed. We just don’t know how to make them available. That is exactly why > I said your focus should be getting a release built. > >>>> > >>>> Ralph > >>>> > >>>>> On Apr 6, 2020, at 10:15 PM, Davyd McColl wrote: > >>>>> > >>>>> That sounds promising, and I'm aware that I'm probably being a > little annoying by now, but I've also noticed that the source package is > version is at 2.0.9 where the latest release package version is 2.0.8. That > version was bumped 3 years ago. In between the last release date and last > commits are commits including at least 2 PR merges (42 and 23 ), both of > which seen significant. > >>>>> > >>>>> I guess what I'm asking is what's holding up the 2.0.9 release? If > I'm to fork, PR and even if that PR is accepted, how do I avoid the fate of > 2.0.9? > >>>>> > >>>>> Or is that something I can assist with right now? > >>>>> > >>>>> Please understand where I'm coming from: I'd really like to keep > log4net alive, but, like anyone, I have limited time resources, so I'd > prefer to spend that time on tasks with some reasonable probability of > success. > >>>>> > >>>>> Thanks > >>>>> -d > >>>>> > >>>>> > >>>>>> On April 6, 2020 23:00:36 Ralph Goers wrote: > >>>>>> > >>>>>> No. What I am implying is that you would begin the work necessary > to perform a release on a fork. When you are ready you would submit a PR > and one or more of the existing PMC members would review that and merge it. > You would then collaborate with us to get the release published. > >>>>>> > >>>>>> There is a big difference between us reviewing PRs and merging them > for stuff we know little about vs us providing the karma you will need to > formally get a release done. > >>>>>> > >>>>>> Ralph > >>>>>> > >>>>>>>> On Apr 6, 2020, at 12:57 PM, Davyd McColl wrote: > >>>>>>> Unfortunately, this would suggest that forking and publishing > under a different package name is probably the best idea. There are, as > noted before, 34 stagnated pull requests currently at GitHub, many of which > haven't seen any attention since 2018. It would seem to be a fool's errand > to open a 35th I'm hopes that it would be the one to get attention. > >>>>>>> If I'm wrong (and I'd love to be) please correct me. > >>>>>>> -d > >>>>>>> On April 6, 2020 15:59:26 Apache wrote: > >>>>>>>> The only requirement to become an experienced open source > developer is passion. Open source developers are just people who like to > work on code that everyone can use. That’s it. If you have the time, can > help with the technical problems needed to get the project moving, and can > collaborate with others you have everything you need. > >>>>>>>> Yes, the code base is still at Github and nothing has been done > that can’t be undone. But for the PMC to move the project out of dormant > status you would first need to demonstrate progress, which might mean > collaborating on a private fork until you are ready to merge it. > >>>>>>>> Ralph > >>>>>>>>> On Apr 6, 2020, at 1:10 AM, Tim Sargent wrote: > >>>>>>>>> I remember reading the call for .NET devs (a few years back) to > help with > >>>>>>>>> the .NET core version for Log4Net. That's about the time I > joined the > >>>>>>>>> mailing list. > >>>>>>>>> As I understand it, dormant just means it's no longer being > maintained, but > >>>>>>>>> the current version is still available for download and use via > NuGet. > >>>>>>>>> I've toyed with the idea of getting involved in an open source > project, > >>>>>>>>> which is why I originally joined the list. Unfortunately, I > don't think I > >>>>>>>>> have the background in open source projects to be an effective > contributor, > >>>>>>>>> let alone sponsor. I'm very experienced in .NET (having been > doing it > >>>>>>>>> since it was in its final preview for 1.0), and I have > experience with unit > >>>>>>>>> tests, automated builds and release pipelines (though it's all > MS based via > >>>>>>>>> TFS and MSTest). > >>>>>>>>> Having said that, it sounds like Mr McColl has a strong interest > in keeping > >>>>>>>>> it alive, and I'd be happy to offer assistance in any way he > finds > >>>>>>>>> beneficial. > >>>>>>>>> Thanks. > >>>>>>>>>> On Mon, Apr 6, 2020 at 12:50 AM Apache wrote: > >>>>>>>>>> No one is ever happy moving a project to dormant status. But it > is unfair > >>>>>>>>>> to users to let them think the project is being maintained when > the reality > >>>>>>>>>> is quite different than that. > >>>>>>>>>> The main issue that needs to be overcome is getting a release > out. The ASF > >>>>>>>>>> has some requirements around releases that have to be met, but > that isn’t > >>>>>>>>>> the hard part. Most users want convenience binaries and no one > who is > >>>>>>>>>> active knows how to do that. There is a documented process in > confluence > >>>>>>>>>> but I have no idea how accurate it is. > >>>>>>>>>> Once a release is able to be cut getting assistance from others > would > >>>>>>>>>> probably be easier. > >>>>>>>>>> Also, the ASF infra team really doesn’t care about the status > of the > >>>>>>>>>> project and is not a driving force in this. > >>>>>>>>>> To be honest, log4cxx was in a similar position. But that > project has had > >>>>>>>>>> a couple of people come forward and are working towards a > release. We hope > >>>>>>>>>> they succeed. > >>>>>>>>>> Ralph > >>>>>>>>>>>> On Apr 5, 2020, at 11:56 PM, Davyd McColl wrote: > >>>>>>>>>>> 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. * > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> -- > >>> Matt Sicker > >> > >> > > > > > > -- > > Matt Sicker > > > -- Dominik Psenner
