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