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