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
