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 <[email protected]> wrote:
What you are seeing is exactly what I have been saying. The major problem is 
that none of the existing logging services committers know how to perform a 
release. We know there have been fixes committed that are needed. We just don’t 
know how to make them available. That is exactly why I said your focus should 
be getting a release built.

Ralph

> On Apr 6, 2020, at 10:15 PM, Davyd McColl wrote:
>
> That sounds promising, and I'm aware that I'm probably being a little 
> annoying by now, but I've also noticed that the source package is version is 
> at 2.0.9 where the latest release package version is 2.0.8. That version was 
> bumped 3 years ago. In between the last release date and last commits are 
> commits including at least 2 PR merges (42 and 23 ), both of which seen 
> significant.
>
> I guess what I'm asking is what's holding up the 2.0.9 release? If I'm to 
> fork, PR and even if that PR is accepted, how do I avoid the fate of 2.0.9?
>
> Or is that something I can assist with right now?
>
> Please understand where I'm coming from: I'd really like to keep log4net 
> alive, but, like anyone, I have limited time resources, so I'd prefer to 
> spend that time on tasks with some reasonable probability of success.
>
> Thanks
> -d
>
>
>> On April 6, 2020 23:00:36 Ralph Goers wrote:
>>
>> No. What I am implying is that you would begin the work necessary to perform 
>> a release on a fork. When you are ready you would submit a PR and one or 
>> more of the existing PMC members would review that and merge it. You would 
>> then collaborate with us to get the release published.
>>
>> There is a big difference between us reviewing PRs and merging them for 
>> stuff we know little about vs us providing the karma you will need to 
>> formally get a release done.
>>
>> Ralph
>>
>>>> On Apr 6, 2020, at 12:57 PM, Davyd McColl wrote:
>>> Unfortunately, this would suggest that forking and publishing under a 
>>> different package name is probably the best idea. There are, as noted 
>>> before, 34 stagnated pull requests currently at GitHub, many of which 
>>> haven't seen any attention since 2018. It would seem to be a fool's errand 
>>> to open a 35th I'm hopes that it would be the one to get attention.
>>> If I'm wrong (and I'd love to be) please correct me.
>>> -d
>>> On April 6, 2020 15:59:26 Apache wrote:
>>>> The only requirement to become an experienced open source developer is 
>>>> passion. Open source developers are just people who like to work on code 
>>>> that everyone can use. That’s it. If you have the time, can help with the 
>>>> technical problems needed to get the project moving, and can collaborate 
>>>> with others you have everything you need.
>>>> Yes, the code base is still at Github and nothing has been done that can’t 
>>>> be undone. But for the PMC to move the project out of dormant status you 
>>>> would first need to demonstrate progress, which might mean collaborating 
>>>> on a private fork until you are ready to merge it.
>>>> Ralph
>>>>> On Apr 6, 2020, at 1:10 AM, Tim Sargent wrote:
>>>>> I remember reading the call for .NET devs (a few years back) to help with
>>>>> the .NET core version for Log4Net. That's about the time I joined the
>>>>> mailing list.
>>>>> As I understand it, dormant just means it's no longer being maintained, 
>>>>> but
>>>>> the current version is still available for download and use via NuGet.
>>>>> I've toyed with the idea of getting involved in an open source project,
>>>>> which is why I originally joined the list. Unfortunately, I don't think I
>>>>> have the background in open source projects to be an effective 
>>>>> contributor,
>>>>> let alone sponsor. I'm very experienced in .NET (having been doing it
>>>>> since it was in its final preview for 1.0), and I have experience with 
>>>>> unit
>>>>> tests, automated builds and release pipelines (though it's all MS based 
>>>>> via
>>>>> TFS and MSTest).
>>>>> Having said that, it sounds like Mr McColl has a strong interest in 
>>>>> keeping
>>>>> it alive, and I'd be happy to offer assistance in any way he finds
>>>>> beneficial.
>>>>> Thanks.
>>>>>> On Mon, Apr 6, 2020 at 12:50 AM Apache wrote:
>>>>>> No one is ever happy moving a project to dormant status. But it is unfair
>>>>>> to users to let them think the project is being maintained when the 
>>>>>> reality
>>>>>> is quite different than that.
>>>>>> The main issue that needs to be overcome is getting a release out. The 
>>>>>> ASF
>>>>>> has some requirements around releases that have to be met, but that isn’t
>>>>>> the hard part. Most users want convenience binaries and no one who is
>>>>>> active knows how to do that. There is a documented process in confluence
>>>>>> but I have no idea how accurate it is.
>>>>>> Once a release is able to be cut getting assistance from others would
>>>>>> probably be easier.
>>>>>> Also, the ASF infra team really doesn’t care about the status of the
>>>>>> project and is not a driving force in this.
>>>>>> To be honest, log4cxx was in a similar position. But that project has had
>>>>>> a couple of people come forward and are working towards a release. We 
>>>>>> hope
>>>>>> they succeed.
>>>>>> Ralph
>>>>>>>> On Apr 5, 2020, at 11:56 PM, Davyd McColl wrote:
>>>>>>> Hi all
>>>>>>> I'm new to this list, been using log4net for around 9 years, and only
>>>>>> this
>>>>>>> week discovered that it is being made dormant (and what that means).
>>>>>>> I've been told that the team has been looking for outside help for
>>>>>> around 2
>>>>>>> years, with no-one forthcoming. Unfortunately, as I say, this is the
>>>>>> first
>>>>>>> I've heard of it. I'd like to keep log4net alive because it's used
>>>>>>> ubiquitously and I think it's a valuable project.
>>>>>>> I publish my own nuget packages (https://www.nuget.org/profiles/davydm)
>>>>>>> though obviously, not with the same methodologies of the existing 
>>>>>>> log4net
>>>>>>> infrastructure. I see that there's a 2.0.9 release that could 
>>>>>>> potentially
>>>>>>> happen (as per the source), whilst 2.0.8 is still the current release, 
>>>>>>> so
>>>>>>> I'm assuming there's something holding that up. I also see 34 pull
>>>>>> requests
>>>>>>> on GitHub which are in different states of activity, but many have been
>>>>>>> dormant since 2018.
>>>>>>> I'd like to help, but I'm not sure where to start with the log4net infra
>>>>>> (I
>>>>>>> hear there's Jira (I've had little experience) and Jenkins (I've had
>>>>>>> reasonable experience, but not with pipelines)). I'm not even sure what
>>>>>> the
>>>>>>> state of play is for that infra. I'm sure there are good reasons for
>>>>>> making
>>>>>>> the project dormant -- some of those may include the desire to free up
>>>>>>> infra which could be used elsewhere (or just not paid for).
>>>>>>> As I say, I'd like to keep log4net alive. I see a few options here:
>>>>>>> 1. I learn your infra and your processes. I integrate and try to keep
>>>>>>> things pretty-much as they were (though I'm sure some things would have
>>>>>> to
>>>>>>> change -- all things do). I don't mind spending the time learning the
>>>>>>> domain, if that's agreeable to everyone and the project retains it's
>>>>>>> original branding and status. One thing I'm concerned about here is the
>>>>>>> dormant backlog
>>>>>>> 2. As above, with a bit of a clean-slate philosophy: I'd like to remove
>>>>>> all
>>>>>>> backlog items that aren't critical and start with the least outstanding
>>>>>>> stuff possible. If a report is important, it will be reported again.
>>>>>> Trying
>>>>>>> to trace down the authors and origins of 2+year-old reports is going to
>>>>>> be
>>>>>>> frustrating. Issues which aren't attended to just become noise in the
>>>>>>> backlog, imo.
>>>>>>> 3. I fork and perform the "clean slate" approach of above, inviting
>>>>>> others
>>>>>>> to use my variant and log issues there. Uptake will naturally be slow 
>>>>>>> (if
>>>>>>> even noticeable), which will give me time to deal with incoming issues.
>>>>>> On
>>>>>>> the other hand, I'd have full control and no need to bother anyone else.
>>>>>> I
>>>>>>> would have to come up with a new name and make it clear that it's a 
>>>>>>> fork,
>>>>>>> though also make it clear I'd be standing on the shoulders of giants.
>>>>>>> Personally, I'd like (1) because it keeps the project that people rely 
>>>>>>> on
>>>>>>> alive. Since I'm new to the mailing list, I can't discern yet the
>>>>>> sentiment
>>>>>>> towards the project, except that everyone was quite happy to have it 
>>>>>>> made
>>>>>>> dormant, so it feels like there's not a lot of desire to keep it going 
>>>>>>> --
>>>>>>> which is ok: everything comes to an end at some point, and, as stated
>>>>>>> earlier, I'm sure there are good reasons for making log4net dormant. As 
>>>>>>> a
>>>>>>> consumer of log4net, I'd much rather not have to switch over to another
>>>>>>> framework once there's an issue which affects me more than my logged one
>>>>>>> (inability to flush logs -- it was on a proof-of-concept project, so it
>>>>>>> isn't _that_ important to have the functionality right now).
>>>>>>> Apologies for the rambling message. I was prompted to reach out by Ralph
>>>>>>> Goers in the discussion for LOG4NET-606, so I hope I haven't been a
>>>>>> bother.
>>>>>>> -d
>>>>>>> --
>>>>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>>>>>> If you say that getting the money is the most important thing
>>>>>>> You will spend your life completely wasting your time
>>>>>>> You will be doing things you don't like doing
>>>>>>> In order to go on living
>>>>>>> That is, to go on doing things you don't like doing
>>>>>>> Which is stupid.
>>>>>>> - Alan Watts
>>>>>>> https://www.youtube.com/watch?v=-gXTZM_uPMY
>>>>>>> *Quidquid latine dictum sit, altum sonatur. *
>>
>>
>
>
>


Reply via email to