log4net: resurrection

[Davyd McColl]

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

[Log4Net]: resurrection

[Davyd McColl]

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, renamed within the project to package-icon.png for clarity

Next up:
dotnet core tooling wants sdks for net20 and net35 to be installed on the host. 
Alternatively, we could install all of Build Tools 2019 on the host. I think 
the former might be neater. At any rate, I now have to figure out enough docker 
to be dangerous and get a standalone build environment up and running.

-d

Re: log4net: resurrection

[Apache]

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

Re: log4net: resurrection

[Tim Sargent]

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
>

Re: log4net: resurrection

[Apache]

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 at

Re: log4net: resurrection

[Davyd McColl]

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 possibl

Re: log4net: resurrection

[Ralph Goers]

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 no

Re: log4net: resurrection

[Davyd McColl]

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 e

Re: log4net: resurrection

[Apache]

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 

Re: log4net: resurrection

[Davyd McColl]

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 spons

Re: log4net: resurrection

[Matt Sicker]

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 ne

Re: log4net: resurrection

[Davyd McColl]

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 e

Re: log4net: resurrection

[Matt Sicker]

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* sites apparently), so if you
want to get rid of that, you'll need to convert the site build as
well. Whatever tooling makes most sense is fine with us!

On Tue, 7 Apr 2020 at 10:42, 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 th

Re: log4net: resurrection

[Ralph Goers]

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 
>

Re: log4net: resurrection

[Matt Sicker]

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

Re: log4net: resurrection

[Davyd McColl]

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 pro

Re: log4net: resurrection

[Ralph Goers]

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

Re: log4net: resurrection

[Davyd McColl]

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

Re: log4net: resurrection

[Dominik Psenner]

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

Re: log4net: resurrection

[Davyd McColl]

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

Re: log4net: resurrection

[Tim Sargent]

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

Re: log4net: resurrection

[Remko Popma]

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

Re: log4net: resurrection

[Tim Sargent]

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

Re: log4net: resurrection

[Ralph Goers]

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

[Log4Net] resurrection update

[Davyd McColl]

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 contains the 
solution and two subfolders for the project main and tests
3. Tests all pass, though I had to modify one around remoting slightly.
4. Current build targets: net20, net35, net40, net45, netstandard1.3, 
netstandard2.0 (I saw requests for a netstandard2.0 target and it wasn't much 
to add in, though I expect future enhancements which will only target 
netstandard2.0+)

Next up:
- ensure ClientProfile builds happen
- use zarro to enable CLI build
- ensure .nupkg is built correctly
- investigate how to get this working without requiring a mission at the CI 
server (ie, learn enough docker to be dangerous)
- raise a PR

-d

Re: [Log4Net]: resurrection

[Dominik Psenner]

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 several of the targets.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sat, Apr 18, 2020, 17:02 Davyd McColl  wrote:

> 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, renamed within the project to package-icon.png for
> clarity
>
> Next up:
> dotnet core tooling wants sdks for net20 and net35 to be installed on the
> host. Alternatively, we could install all of Build Tools 2019 on the host.
> I think the former might be neater. At any rate, I now have to figure out
> enough docker to be dangerous and get a standalone build environment up and
> running.
>
> -d

Re: [Log4Net]: resurrection

[Dominik Psenner]

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
migrated to the new SDK style, it would be supported by the dotnet
commandline tool and as such the following targets can be built by using
the dotnet build command:

https://docs.microsoft.com/en-us/dotnet/standard/frameworks
https://docs.microsoft.com/it-it/dotnet/core/tools/dotnet-build

This would greatly integrate with msbuild inline tasks which could be used
to build site and other non-code assemblies:

https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-inline-tasks?view=vs-2019

Cheers,
Dominik

On Sun, 19 Apr 2020 at 10:41, Dominik Psenner  wrote:

> 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 several of the targets.
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
>
> On Sat, Apr 18, 2020, 17:02 Davyd McColl  wrote:
>
>> 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, renamed within the project to package-icon.png for
>> clarity
>>
>> Next up:
>> dotnet core tooling wants sdks for net20 and net35 to be installed on the
>> host. Alternatively, we could install all of Build Tools 2019 on the host.
>> I think the former might be neater. At any rate, I now have to figure out
>> enough docker to be dangerous and get a standalone build environment up and
>> running.
>>
>> -d
>
>

-- 
Dominik Psenner

Re: [Log4Net]: resurrection

[Davyd McColl]

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.


There is a nuget package from Microsoft which provides the API only (so one 
can build) - it contains API for 2 and some 4.x variants. There's a 
3rd-party nuget package for 3.5. alternatively, I can get mono to provide 
the framework apis, though my current mechanism for doing so doesn't seem 
to be properly picked up for 2.0 or 3.5 (but I can force it with, eg, a 
2.0-only build and an msbuild prop on the cli). Mono would be nice because 
the project could be built anywhere, but I'm also ok with a windows docker 
image and the 2 sdks installed. Anyways, these are the options I'm 
currently checking out. The docker info in the develop branch will surely 
help, so thanks again.


-d


On April 19, 2020 11:11:46 Dominik Psenner  wrote:


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
migrated to the new SDK style, it would be supported by the dotnet
commandline tool and as such the following targets can be built by using
the dotnet build command:

https://docs.microsoft.com/en-us/dotnet/standard/frameworks
https://docs.microsoft.com/it-it/dotnet/core/tools/dotnet-build

This would greatly integrate with msbuild inline tasks which could be used
to build site and other non-code assemblies:

https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-inline-tasks?view=vs-2019

Cheers,
Dominik

On Sun, 19 Apr 2020 at 10:41, Dominik Psenner  wrote:


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 several of the targets.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sat, Apr 18, 2020, 17:02 Davyd McColl  wrote:


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, renamed within the project to package-icon.png for
clarity

Next up:
dotnet core tooling wants sdks for net20 and net35 to be installed on the
host. Alternatively, we could install all of Build Tools 2019 on the host.
I think the former might be neater. At any rate, I now have to figure out
enough docker to be dangerous and get a standalone build environment up and
running.

-d





--
Dominik Psenner

Re: [Log4Net]: resurrection

[Matt Sicker]

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 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.
>
> There is a nuget package from Microsoft which provides the API only (so
> one
> can build) - it contains API for 2 and some 4.x variants. There's a
> 3rd-party nuget package for 3.5. alternatively, I can get mono to provide
> the framework apis, though my current mechanism for doing so doesn't seem
> to be properly picked up for 2.0 or 3.5 (but I can force it with, eg, a
> 2.0-only build and an msbuild prop on the cli). Mono would be nice because
> the project could be built anywhere, but I'm also ok with a windows docker
> image and the 2 sdks installed. Anyways, these are the options I'm
> currently checking out. The docker info in the develop branch will surely
> help, so thanks again.
>
> -d
>
>
> On April 19, 2020 11:11:46 Dominik Psenner  wrote:
>
> > 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
> > migrated to the new SDK style, it would be supported by the dotnet
> > commandline tool and as such the following targets can be built by using
> > the dotnet build command:
> >
> > https://docs.microsoft.com/en-us/dotnet/standard/frameworks
> > https://docs.microsoft.com/it-it/dotnet/core/tools/dotnet-build
> >
> > This would greatly integrate with msbuild inline tasks which could be
> used
> > to build site and other non-code assemblies:
> >
> >
> https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-inline-tasks?view=vs-2019
> >
> > Cheers,
> > Dominik
> >
> > On Sun, 19 Apr 2020 at 10:41, Dominik Psenner 
> wrote:
> >
> >> You may find the develop and other branches useful:
> >>
> >>
> https://github.com/apache/logging-log4net/tree/develop/buildtools/docker
> >> <
> https://github.com/apache/logging-log4net/tree/feature/netstandard-2.0/buildtools/docker
> >
> >>
> >> There are dockerfiles along with shell scripts that used to work for
> >> building several of the targets.
> >> --
> >> Sent from my phone. Typos are a kind gift to anyone who happens to find
> >> them.
> >>
> >> On Sat, Apr 18, 2020, 17:02 Davyd McColl  wrote:
> >>
> >>> 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, renamed within the project to
> package-icon.png for
> >>> clarity
> >>>
> >>> Next up:
> >>> dotnet core tooling wants sdks for net20 and net35 to be installed on
> the
> >>> host. Alternatively, we could install all of Build Tools 2019 on the
> host.
> >>> I think the former might be neater. At any rate, I now have to figure
> out
> >>> enough docker to be dangerous and get a standalone build environment
> up and
> >>> running.
> >>>
> >>> -d
> >>
> >>
> >
> > --
> > Dominik Psenner
>
>
> --
Matt Sicker 

[log4net] resurrection update

[Davyd McColl]

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 some point, this build 
artifact has to be imported into Apache infra to be published -- I'm not sure 
if figuring that out should happen as part of the PR, or after; I'm quite happy 
to help with this, but will need some serious guidance (:

Last build is here: 
https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/32615159 -- 
there's a .nupkg artifact included, if anyone wants to check it out.

I'd like to tidy up my commit history a little (there's a metric boatload of 
experimental commits purely experimenting with external build systems), but I'm 
about ready to PR, I think.

When there was mention of docker earlier, there wasn't mention of _host_ 
environment. Is docker available on windows, for windows containers? If not, 
I'll cull that work from the PR (though I definitely have other uses for it), 
assuming that AppVeyer is acceptable, as per prior communications.

Thanks
-d

Re: [Log4Net] resurrection update

[Matt Sicker]

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 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
> contains the solution and two subfolders for the project main and tests
> 3. Tests all pass, though I had to modify one around remoting slightly.
> 4. Current build targets: net20, net35, net40, net45, netstandard1.3,
> netstandard2.0 (I saw requests for a netstandard2.0 target and it wasn't
> much to add in, though I expect future enhancements which will only target
> netstandard2.0+)
>
> Next up:
> - ensure ClientProfile builds happen
> - use zarro to enable CLI build
> - ensure .nupkg is built correctly
> - investigate how to get this working without requiring a mission at the
> CI server (ie, learn enough docker to be dangerous)
> - raise a PR
>
> -d

-- 
Matt Sicker 

Re: [log4net] resurrection update

[Ralph Goers]

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 
https://cwiki.apache.org/confluence/display/LOGGING/Log4j+2+Release+Process. 

In a nutshell, the mail requirements of a release are
1. It contain a LICENSE file.
2. It contain a NOTICES file if one is needed.
3. It should contain a RELEASE_NOTES file, but this is not required.
4. It must compile (notice the ASF requirements don’t even require it passing 
unit tests)
5. It must be signed. Getting a trusted signing key can take some time so help 
may be required for that.
6. It must be uploaded to https://dist.apache.org/repos/dist/release/logging/. 
This requires privileges that only Logging PMC and ASF members have. 

Note that the ASF only requires that the source code be packaged for a release. 
However, most projects provide “convenience” binaries since that is what most 
users really want. These binaries can also be uploaded to the distribution 
directory and may be distributed in other ways that make it easy for uses to 
obtain them. For example, all Log4j releases are published to the ASF Nexus 
repository which will forward them to the Maven Central Repository.

As for Docker, since you are using that as a build environment you can make any 
requirements you want on the platform docker runs on. That said, although I 
have never done it (since I haven’t had a computer natively running Windows in 
at least 10 years), Docker does seem to run on Windows - 
https://docs.docker.com/docker-for-windows/.

Have you documented the instructions to perform the build somewhere?

Ralph





> On May 3, 2020, at 9:23 AM, Davyd McColl  wrote:
> 
> 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 some point, this build 
> artifact has to be imported into Apache infra to be published -- I'm not sure 
> if figuring that out should happen as part of the PR, or after; I'm quite 
> happy to help with this, but will need some serious guidance (:
> 
> Last build is here: 
> https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/32615159 -- 
> there's a .nupkg artifact included, if anyone wants to check it out.
> 
> I'd like to tidy up my commit history a little (there's a metric boatload of 
> experimental commits purely experimenting with external build systems), but 
> I'm about ready to PR, I think.
> 
> When there was mention of docker earlier, there wasn't mention of _host_ 
> environment. Is docker available on windows, for windows containers? If not, 
> I'll cull that work from the PR (though I definitely have other uses for it), 
> assuming that AppVeyer is acceptable, as per prior communications.
> 
> Thanks
> -d

Re: [log4net] resurrection update

[Davyd McColl]

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 
other Apache projects consume AppVeyer. AppVeyer was suggested as a known 
quantity. 

Either way, I'm going to need help: either to have docker installed on an 
existing windows infra machine, and targeting windows containers, or doing 
whatever is accepted as a reasonable workflow to get the artifacts from AppVeyer

As for signing, the .snk is included in the repo and there's a note in the 
readme that it was done that way on purpose, so there should be no need to sort 
that out. Security around upload to nuget.org prevents nefarious packages from 
being released -- I gather that was considered good enough.

I'll clean up commits and raise a PR (hopefully tomorrow), but I'm going to 
need some help with this as I've done what I can: build, test (tests all pass) 
and generate the package. From here on out, I'm going to need an Apache buddy 
to get any further, assuming even that my PR is acceptable.

-d
On 2020-05-03 19:10:16, Ralph Goers  wrote:
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 
https://cwiki.apache.org/confluence/display/LOGGING/Log4j+2+Release+Process.

In a nutshell, the mail requirements of a release are
1. It contain a LICENSE file.
2. It contain a NOTICES file if one is needed.
3. It should contain a RELEASE_NOTES file, but this is not required.
4. It must compile (notice the ASF requirements don’t even require it passing 
unit tests)
5. It must be signed. Getting a trusted signing key can take some time so help 
may be required for that.
6. It must be uploaded to https://dist.apache.org/repos/dist/release/logging/. 
This requires privileges that only Logging PMC and ASF members have.

Note that the ASF only requires that the source code be packaged for a release. 
However, most projects provide “convenience” binaries since that is what most 
users really want. These binaries can also be uploaded to the distribution 
directory and may be distributed in other ways that make it easy for uses to 
obtain them. For example, all Log4j releases are published to the ASF Nexus 
repository which will forward them to the Maven Central Repository.

As for Docker, since you are using that as a build environment you can make any 
requirements you want on the platform docker runs on. That said, although I 
have never done it (since I haven’t had a computer natively running Windows in 
at least 10 years), Docker does seem to run on Windows - 
https://docs.docker.com/docker-for-windows/.

Have you documented the instructions to perform the build somewhere?

Ralph





> On May 3, 2020, at 9:23 AM, Davyd McColl wrote:
>
> 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 some point, this build 
> artifact has to be imported into Apache infra to be published -- I'm not sure 
> if figuring that out should happen as part of the PR, or after; I'm quite 
> happy to help with this, but will need some serious guidance (:
>
> Last build is here: 
> https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/32615159 -- 
> there's a .nupkg artifact included, if anyone wants to check it out.
>
> I'd like to tidy up my commit history a little (there's a metric boatload of 
> experimental commits purely experimenting with external build systems), but 
> I'm about ready to PR, I think.
>
> When there was mention of docker earlier, there wasn't mention of _host_ 
> environment. Is docker available on windows, for windows containers? If not, 
> I'll cull that work from the PR (though I definitely have other uses for it), 
> assuming that AppVeyer is acceptable, as per prior communications.
>
> Thanks
> -d

Re: [log4net] resurrection update

[Ralph Goers]

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 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 other Apache projects consume AppVeyer. AppVeyer was suggested as a 
> known quantity. 
> 
> Either way, I'm going to need help: either to have docker installed on an 
> existing windows infra machine, and targeting windows containers, or doing 
> whatever is accepted as a reasonable workflow to get the artifacts from 
> AppVeyer
> 
> As for signing, the .snk is included in the repo and there's a note in the 
> readme that it was done that way on purpose, so there should be no need to 
> sort that out. Security around upload to nuget.org  
> prevents nefarious packages from being released -- I gather that was 
> considered good enough.
> 
> I'll clean up commits and raise a PR (hopefully tomorrow), but I'm going to 
> need some help with this as I've done what I can: build, test (tests all 
> pass) and generate the package. From here on out, I'm going to need an Apache 
> buddy to get any further, assuming even that my PR is acceptable.
> 
> -d
> On 2020-05-03 19:10:16, Ralph Goers  > wrote:
> 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 
> https://cwiki.apache.org/confluence/display/LOGGING/Log4j+2+Release+Process.
> 
> In a nutshell, the mail requirements of a release are
> 1. It contain a LICENSE file.
> 2. It contain a NOTICES file if one is needed.
> 3. It should contain a RELEASE_NOTES file, but this is not required.
> 4. It must compile (notice the ASF requirements don’t even require it passing 
> unit tests)
> 5. It must be signed. Getting a trusted signing key can take some time so 
> help may be required for that.
> 6. It must be uploaded to 
> https://dist.apache.org/repos/dist/release/logging/. This requires privileges 
> that only Logging PMC and ASF members have.
> 
> Note that the ASF only requires that the source code be packaged for a 
> release. However, most projects provide “convenience” binaries since that is 
> what most users really want. These binaries can also be uploaded to the 
> distribution directory and may be distributed in other ways that make it easy 
> for uses to obtain them. For example, all Log4j releases are published to the 
> ASF Nexus repository which will forward them to the Maven Central Repository.
> 
> As for Docker, since you are using that as a build environment you can make 
> any requirements you want on the platform docker runs on. That said, although 
> I have never done it (since I haven’t had a computer natively running Windows 
> in at least 10 years), Docker does seem to run on Windows - 
> https://docs.docker.com/docker-for-windows/.
> 
> Have you documented the instructions to perform the build somewhere?
> 
> Ralph
> 
> 
> 
> 
> 
>> On May 3, 2020, at 9:23 AM, Davyd McColl wrote:
>> 
>> 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 some point, this build 
>> artifact has to be imported into Apache infra to be published -- I'm not 
>> sure if figuring that out should happen as part of the PR, or after; I'm 
>> quite happy to help with this, but will need some serious guidance (:
>> 
>> Last build is here: 
>> https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/32615159 
>> -- there's a .nupkg artifact included, if anyone wants to check it out.
>> 
>> I'd like to tidy up my commit history a little (there's a metric boatload of 
>> experimental commits purely experimenting with external build systems), but 
>> I'm about ready to PR, I think.
>> 
>> When there was mention of docker earlier, there wasn't mention of _host_ 
>> environment. Is docker available on windows, for windows containers? If not, 
>> I'll cull that work from the PR (though I definitely have other uses for 
>> it), assuming that AppVeyer is acceptable, as per prior communications.
>> 
>> Thanks
>> -d

Re: [log4net] resurrection update

[Matt Sicker]

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 AppVeyor, then there's no need to figure out a
duplicate Jenkins pipeline.

For signing, there's a gpg signature that needs to be created for
Apache releases independent of any application-specific signatures
that are included (e.g., a jar file can contain signatures of the
files inside it using a code signing certificate, and I'd assume
you're talking about something similar for the nuget package). If we
also need a code signing certificate (e.g., for an app store release
type of thing), then that will complicate things slightly, but there
is some sort of code signing service here at Apache nowadays (in
theory, it'd be useful if we made any OS-specific packages for any GUI
apps).

One thing to keep in mind about the gpg signing is that it should be
done on your own computer, not in a CI environment. The only potential
exception around that would be for fully binary reproducible builds,
but that's its own project. In the case of AppVeyor, that could mean
downloading the release artifacts from it, testing them out, then
signing and uploading the files for staging the release.

On Sun, 3 May 2020 at 12:23, Davyd McColl  wrote:
>
> 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 other Apache projects consume AppVeyer. AppVeyer was suggested as a 
> known quantity.
>
> Either way, I'm going to need help: either to have docker installed on an 
> existing windows infra machine, and targeting windows containers, or doing 
> whatever is accepted as a reasonable workflow to get the artifacts from 
> AppVeyer
>
> As for signing, the .snk is included in the repo and there's a note in the 
> readme that it was done that way on purpose, so there should be no need to 
> sort that out. Security around upload to nuget.org prevents nefarious 
> packages from being released -- I gather that was considered good enough.
>
> I'll clean up commits and raise a PR (hopefully tomorrow), but I'm going to 
> need some help with this as I've done what I can: build, test (tests all 
> pass) and generate the package. From here on out, I'm going to need an Apache 
> buddy to get any further, assuming even that my PR is acceptable.
>
> -d
> On 2020-05-03 19:10:16, Ralph Goers  wrote:
> 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 
> https://cwiki.apache.org/confluence/display/LOGGING/Log4j+2+Release+Process.
>
> In a nutshell, the mail requirements of a release are
> 1. It contain a LICENSE file.
> 2. It contain a NOTICES file if one is needed.
> 3. It should contain a RELEASE_NOTES file, but this is not required.
> 4. It must compile (notice the ASF requirements don’t even require it passing 
> unit tests)
> 5. It must be signed. Getting a trusted signing key can take some time so 
> help may be required for that.
> 6. It must be uploaded to 
> https://dist.apache.org/repos/dist/release/logging/. This requires privileges 
> that only Logging PMC and ASF members have.
>
> Note that the ASF only requires that the source code be packaged for a 
> release. However, most projects provide “convenience” binaries since that is 
> what most users really want. These binaries can also be uploaded to the 
> distribution directory and may be distributed in other ways that make it easy 
> for uses to obtain them. For example, all Log4j releases are published to the 
> ASF Nexus repository which will forward them to the Maven Central Repository.
>
> As for Docker, since you are using that as a build environment you can make 
> any requirements you want on the platform docker runs on. That said, although 
> I have never done it (since I haven’t had a computer natively running Windows 
> in at least 10 years), Docker does seem to run on Windows - 
> https://docs.docker.com/docker-for-windows/.
>
> Have you documented the instructions to perform the build somewhere?
>
> Ralph
>
>
>
>
>
> > On May 3, 2020, at 9:23 AM, Davyd McColl wrote:
> >
> > 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 some point, this build 

Re: [log4net] resurrection update

[Davyd McColl]

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 
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 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 other Apache projects consume AppVeyer. AppVeyer was suggested as a 
> known quantity.
>
> Either way, I'm going to need help: either to have docker installed on an 
> existing windows infra machine, and targeting windows containers, or doing 
> whatever is accepted as a reasonable workflow to get the artifacts from 
> AppVeyer
>
> As for signing, the .snk is included in the repo and there's a note in the 
> readme that it was done that way on purpose, so there should be no need to 
> sort that out. Security around upload to nuget.org prevents nefarious 
> packages from being released -- I gather that was considered good enough.
>
> I'll clean up commits and raise a PR (hopefully tomorrow), but I'm going to 
> need some help with this as I've done what I can: build, test (tests all 
> pass) and generate the package. From here on out, I'm going to need an Apache 
> buddy to get any further, assuming even that my PR is acceptable.
>
> -d
> On 2020-05-03 19:10:16, Ralph Goers > wrote:
> 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 
> https://cwiki.apache.org/confluence/display/LOGGING/Log4j+2+Release+Process.
>
> In a nutshell, the mail requirements of a release are
> 1. It contain a LICENSE file.
> 2. It contain a NOTICES file if one is needed.
> 3. It should contain a RELEASE_NOTES file, but this is not required.
> 4. It must compile (notice the ASF requirements don’t even require it passing 
> unit tests)
> 5. It must be signed. Getting a trusted signing key can take some time so 
> help may be required for that.
> 6. It must be uploaded to 
> https://dist.apache.org/repos/dist/release/logging/. This requires privileges 
> that only Logging PMC and ASF members have.
>
> Note that the ASF only requires that the source code be packaged for a 
> release. However, most projects provide “convenience” binaries since that is 
> what most users really want. These binaries can also be uploaded to the 
> distribution directory and may be distributed in other ways that make it easy 
> for uses to obtain them. For example, all Log4j releases are published to the 
> ASF Nexus repository which will forward them to the Maven Central Repository.
>
> As for Docker, since you are using that as a build environment you can make 
> any requirements you want on the platform docker runs on. That said, although 
> I have never done it (since I haven’t had a computer natively running Windows 
> in at least 10 years), Docker does seem to run on Windows - 
> https://docs.docker.com/docker-for-windows/.
>
> Have you documented the instructions to perform the build somewhere?
>
> Ralph
>
>
>
>
>
>> On May 3, 2020, at 9:23 AM, Davyd McColl wrote:
>>
>> 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 some point, this build 
>> artifact has to be imported into Apache infra to be published -- I'm not 
>> sure if figuring that out should happen as part of the PR, or after; I'm 
>> quite happy to help with this, but will need some serious guidance (:
>>
>> Last build is here: 
>> https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/32615159 
>> -- there's a .nupkg artifact included, if anyone wants to check it out.
>>
>> I'd like to tidy up my commit history a little (there's a metric boatload of 
>> experimental commits purely experimenting with external build systems), but 
>> I'm about ready to PR, I think.
>>
>> When there was mention of docker earlier, there wasn't mention of _host_ 
>> environment. Is docker available on windows, for windows containers? If not, 
>> I'll cull that work from the PR (though I definitely have other uses for 
>> it), assuming that AppVeyer is acceptable, as per prior communications.
>>
>> Thanks
>> -d