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>

Reply via email to