Re: [log4net] resurrection update

Hi all I've raised a PR (https://github.com/apache/logging-log4net/pull/59). I'm sure there's more to be done, process-wise. I'd really appreciate some guidance. -d On 2020-05-03 19:32:14, Ralph Goers wrote: There is nothing that requires the release build to run on ASF hardware if that

Re: [log4net] resurrection update

There is nothing that requires the release build to run on ASF hardware if that helps. I perform all the Log4j releases on my MacBook Pro. That said, I am sure it would be helpful to have Docker available to preform CI builds. Ralph > On May 3, 2020, at 10:23 AM, Davyd McColl wrote: > > Hi

Re: [log4net] resurrection update

I'm not sure if our Jenkins here is set up for Docker on Windows yet as that's even a fairly recent integration being worked on in Jenkins itself right now (mostly around packaging Jenkins in a Windows Docker container, but it's part of the larger experience). If you already have it working on

Re: [log4net] resurrection update

Hi Ralph I'll add documentation about build, though it's either: 1. run the batch file to run the docker image and build through that or 2. let AppVeyer build by itself -- which it does -- and grab the build artifact from that, which I don't currently do, as I'm not sure where to put it or how

Re: [log4net] resurrection update

All releases at the ASF follow the guidelines at https://infra.apache.org/release-publishing.html. Although each project is free the tailor the release process to meed its needs, the end result must comply with what is documented there. For example, Log4j 2 uses

[log4net] resurrection update

Hi all I've been a bit busy with other stuff lately, but played a little catch-up today: - I have a _windows_ docker image (and batch file) which builds log4net fine - I've sorted out AppVeyer -- builds happen fine there too. I get the nuget package as a build artifact -- I'd guess that, at

Re: [Log4Net]: resurrection

And while I don’t have much experience in .net, I’m fairly experienced with Jenkins. On Sun, Apr 19, 2020 at 05:24 Davyd McColl wrote: > Thanks, I'll check out the branch. > > I have already migrated to SDK-style projects. The one requirement to use > the dotnet tooling that I'll need to

Re: [Log4Net]: resurrection

Thanks, I'll check out the branch. I have already migrated to SDK-style projects. The one requirement to use the dotnet tooling that I'll need to resolve is that the host (docker image) will need the .net 2 and 3.5 sdks installed - that's currently the only hurdle to building with dotnet.

Re: [Log4Net]: resurrection

I must mention that the Dockerfiles are invoked from the Jenkinsfile and uses nant and the nant build scripts to build the project. nant is a deadend road and should be replaced. The dockerfiles could stay, providing the future build requisites for the future build scripts. If the project is

Re: [Log4Net]: resurrection

You may find the develop and other branches useful: https://github.com/apache/logging-log4net/tree/develop/buildtools/docker There are dockerfiles along with shell scripts that used to work for building

[Log4Net]: resurrection

A short update (not much to report): - resolved Client profile builds - can manually build a .nupkg, without any warnings   - have updated to , using the term Apache-2.0, as per the url it was pointing to   - have updated to point at the same feather.png the package used to point to online,

Re: [Log4Net] resurrection update

Sounds great so far! You can also look at GitHub Actions to see if there’s anything useful there for CI. That’s relatively new, but there might already be some good .net actions to use. On Mon, Apr 13, 2020 at 09:13 Davyd McColl wrote: > Hi all > > Since there was interest in intermittent

[Log4Net] resurrection update

Hi all Since there was interest in intermittent status updates, here's a short one: 1. Packaged & released my build scripts as an npm module (zarro) 2. Consolidated the netstandard and main log4net projects and re-organised the code locations to be more consistent with .net style: src folder

Re: log4net: resurrection

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 wrote: > > Hi Mr Popma - > > I'm fine keeping it on list - I just didn't

Re: log4net: resurrection

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 wrote: > Tim, why not keep it on-list? > That would allow others to chip in to your efforts with their

Re: log4net: resurrection

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 wrote: > Sounds like there's a plan in place going forward, or at least the > beginnings of a plan. I'm happy to

Re: log4net: resurrection

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

Re: log4net: resurrection

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

Re: log4net: resurrection

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]

Re: log4net: resurrection

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 wrote: Sounds good. If you wouldn’t mind, it

Re: log4net: resurrection

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.

Re: log4net: resurrection

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

Re: log4net: resurrection

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,

Re: log4net: resurrection

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: > >

Re: log4net: resurrection

You'll want to make sure the website (or _a_ website) and documentation are still generated nicely. I see there's still a pom.xml which is likely used for generating the website (pom.xml is usually use for JVM-based builds in general, but we've re-used it for website generation on the other log4*

Re: log4net: resurrection

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

Re: log4net: resurrection

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

Re: log4net: resurrection

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

Re: log4net: resurrection

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

Re: log4net: resurrection

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

Re: log4net: resurrection

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

Re: log4net: resurrection

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

Re: log4net: resurrection

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

Re: log4net: resurrection

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

Re: log4net: resurrection

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

log4net: resurrection

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