So far it looks good (though I'm not a .net developer, so I can't speak from that side). There's one more thing we need from this to make it a proper release. You'll need to add a GPG signature for the artifacts as well. We'll need to import your signing key to https://downloads.apache.org/logging/KEYS for users to verify the release is genuine. Please email me a copy of your public key for that so I can sign and add it to our KEYS file. This key should be an RSA 4096-bit GPG key, and it should also be uploaded to a public keyserver like https://sks-keyservers.net/
For signing the files, add a detached ascii signature file (.asc) for the distributable files. As a bonus, you can also sign the git tag you created with the same key, but that's not required. On Fri, 31 Jul 2020 at 01:28, Davyd McColl <dav...@gmail.com> wrote: > > Apologies if there's any confusion around sender address -- I've already > fluffed this by sending from my work account (default in my mail client) > > -d > > On 2020/07/31 08:26:54, Davyd McColl <davyd.mcc...@codeo.co.za> wrote: > Hi all, I've never done this before, so bear with me if I fluff it: > > This is a proposed vote to release log4net 2.0.9 from PR > https://github.com/apache/logging-log4net/pull/61 > > Release artifacts (including source zip) are at: > https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/34063235/artifacts > Source can be checked out from > https://github.com/fluffynuts/logging-log4net/logging-log4net, tag rel/2.0.9. > I can't push tags to the upstream, but this tag is exactly the same commit as > the last in the PR mentioned above, which was accepted into master a few days > ago. > > Please check out the artifacts & if everyone is ok with what's there, please > can someone with the rights to publish to nuget do so. > > Once I've seen how this process works, I'd like to tackle the CVE that has > been brought up on this list more than once -- it's a simple change which was > already committed to the develop branch some time ago, so there are a couple > of options here: > 1. cherry-pick that commit & do a 2.0.10 release pronto, with only that change > 2. trawl the develop branch to see what else was already solved in there, and > get that out as 2.0.10, and perhaps close out that branch to avoid future > confusion. > > Thanks for your time > -d -- Matt Sicker <boa...@gmail.com>