When you post just prefix the subject with [Log4Net]. Then anyone who isn’t interested will know to ignore it. It also might stir up interest in others to help.
Ralph > On Apr 10, 2020, at 1:45 AM, Tim Sargent <bentwingedb...@gmail.com> wrote: > > Hi Mr Popma - > > I'm fine keeping it on list - I just didn't want to clutter the list > with what others might find to be minutia. Thanks. > > Tim > > On Thu, Apr 9, 2020 at 6:18 PM Remko Popma <remko.po...@gmail.com> wrote: > >> Tim, why not keep it on-list? >> That would allow others to chip in to your efforts with their experience, >> just like you are doing now. :-) >> >> On Thu, Apr 9, 2020 at 5:34 PM Tim Sargent <bentwingedb...@gmail.com> >> wrote: >> >>> Sounds like there's a plan in place going forward, or at least the >>> beginnings of a plan. I'm happy to help - I have a lot of experience >> with >>> automated builds and releases but it's all based on the TFS build and >>> release system. The principles should apply regardless of the system >>> though. >>> >>> Mr McColl - feel free to email me directly if I can be of assistance. >>> Thanks. >>> >>> Tim >>> >>> >>> On Wed, Apr 8, 2020 at 12:50 PM Davyd McColl <dav...@gmail.com> wrote: >>> >>>> The build scripts I made and use do indeed use msbuild (or the dotnet >>>> wrapper around it, depending on environment) - they simply abstract >> away >>>> finding the latest (or requested) version as well as calling >> conventions. >>>> They can also use nuget or the dotnet command for packaging and package >>>> pushing, depending on environment, as well as (currently) nunit or >> dotnet >>>> for running tests. Think of them as orchestration, more than anything >>> else. >>>> >>>> The trick is getting them out of a git submodule (the way they've been >>>> consumed for around 7 years) and ease use by publishing to npm, a task >> I >>>> currently have underway. >>>> >>>> -d >>>> >>>> >>>> On April 8, 2020 21:42:47 Dominik Psenner <dpsen...@gmail.com> wrote: >>>> >>>>> 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 >>>> >>>> >>>> >>> >>
