Re: [VOTE] [log4net] Release 2.0.10
Hi Dominik No, it doesn't. Netstandard 2.0 support is added in addition to the existing netstandard 1.3 target. Whilst I'd really like to diminish the target list of the package (particularly the client profile targets), I'd only be comfortable doing so on a major version change, and I think that mostly I just want to deprecate client profiles to enable easier cross-platform dev (those are the only targets I haven't had joy supporting on Linux so far) -d On September 7, 2020 19:55:51 Dominik Psenner wrote: Hi Does this break support for netstandard1.3 and enforces users to update all their dependants? Best regards -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Sun, Sep 6, 2020, 21:04 Davyd McColl wrote: Hi all I'd like to propose a vote to release 2.0.10 of log4net, with: - updated netstandard 2.0 support from community member NicholasNoise - cherry-picked fix for CVE-2018-1285 (I had to modify slightly since the mechanism used there is outdated for netstandard 2.0, but the principle stands I've created an RC release at GitHub: https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1 and pushed updated site material to the `asf-staging` branch of the logging-log4net-site repo. Thanks -d
[VOTE] [log4net] Release 2.0.10
Hi all I'd like to propose a vote to release 2.0.10 of log4net, with: - updated netstandard 2.0 support from community member NicholasNoise - cherry-picked fix for CVE-2018-1285 (I had to modify slightly since the mechanism used there is outdated for netstandard 2.0, but the principle stands I've created an RC release at GitHub: https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1 and pushed updated site material to the `asf-staging` branch of the logging-log4net-site repo. Thanks -d
Re: [logging-log4net] tag rel/2.0.10 created (now 2105ec8)
Hi Matt In that case, I can create an -rc1 release on GitHub; when everyone is happy, I can upload the accepted binaries to SVN so as not to upload too much junk (: I'll start a vote now (: Thanks again for your help -d On 2020/09/06 20:43:16, Matt Sicker wrote: I don't think we've ever used the GitHub Releases feature here before, though draft releases appear to be limited to being seen only by those with write access to that. For making a release candidate, you'd essentially be making a release for version X but adding -rc1 (or -rc2, etc.) to the tag name to indicate the release candidate. Then in the release vote, we can check out that tag (and any artifacts). For uploading artifacts, you should be able to commit files to this svn repo: https://dist.apache.org/repos/dist/dev/logging/log4net/ It could be an interesting idea to figure out how to use the GitHub Releases feature, though we'd have to make sure that the archives it links to are the same ones that we vote to release. As for signing, please use your gpg key. We've added it to the KEYS file so that users can verify the release signature. The point of signing it is to keep a secure supply chain from the release manager (you in this case) to the end user. [you = Davyd] On Sun, 6 Sep 2020 at 13:33, Davyd McColl wrote: > > Thanks Matt > > I was trying to use GitHub's release feature to create a draft release to > present binaries including signing and hashing, and needed a tag to work > against; however, I think that this process won't work anyway, because I'm > not 100% sure on the visibility of a draft release. I've deleted the tag, and > attempted to create a draft release -- please could you verify if you can > view the draft release? If so (and you can view the binaries), I can start a > vote for 2.0.10. I also added the updated site to the `asf-staging` branch of > the logging repo, so if the release is verifyable at GitHub, I'm ready to > request a vote. The only problem is that I've signed the release artifacts -- > last time, I believe Ralph did, and I'm not sure if my gpg key is acceptable. > > -d > > On 2020/09/06 20:12:46, Matt Sicker wrote: > It's not a good idea to use rel/ tags until after a release vote since > those tags are immutable. If you want to put them in rel/, they'll > need an -rc1 type suffix to distinguish from the resulting release. > > On Sun, 6 Sep 2020 at 13:10, wrote: > > > > This is an automated email from the ASF dual-hosted git repository. > > > > davydm pushed a change to tag rel/2.0.10 > > in repository https://gitbox.apache.org/repos/asf/logging-log4net.git. > > > > > > at 2105ec8 (commit) > > No new revisions were added by this update. > > > > > -- > Matt Sicker -- Matt Sicker
Re: [logging-log4net] tag rel/2.0.10 created (now 2105ec8)
Thanks Matt I was trying to use GitHub's release feature to create a draft release to present binaries including signing and hashing, and needed a tag to work against; however, I think that this process won't work anyway, because I'm not 100% sure on the visibility of a draft release. I've deleted the tag, and attempted to create a draft release -- please could you verify if you can view the draft release? If so (and you can view the binaries), I can start a vote for 2.0.10. I also added the updated site to the `asf-staging` branch of the logging repo, so if the release is verifyable at GitHub, I'm ready to request a vote. The only problem is that I've signed the release artifacts -- last time, I believe Ralph did, and I'm not sure if my gpg key is acceptable. -d On 2020/09/06 20:12:46, Matt Sicker wrote: It's not a good idea to use rel/ tags until after a release vote since those tags are immutable. If you want to put them in rel/, they'll need an -rc1 type suffix to distinguish from the resulting release. On Sun, 6 Sep 2020 at 13:10, wrote: > > This is an automated email from the ASF dual-hosted git repository. > > davydm pushed a change to tag rel/2.0.10 > in repository https://gitbox.apache.org/repos/asf/logging-log4net.git. > > > at 2105ec8 (commit) > No new revisions were added by this update. > -- Matt Sicker
Re: [VOTE] Release Log4Net 2.0.9
Thanks -d On September 5, 2020 21:16:23 Ralph Goers wrote: The changes looked good to me so I went ahead and merged them to the asf-site branch so now they are on the live site. Ralph On Sep 4, 2020, at 11:51 PM, Davyd McColl wrote: Hi Ralph Sorry for wasting your time. I stupidly fixed up some of the the site in the SVN tree last time, and then re-generated before commiting to the github site, so it was still in a 1/2 state and I guess I was looking at the wrong thing in my browser when I checked ): I've updated again and validated that the *2.0.9* links point at the right place; pushed to asf-staging & checked on http://logging.staged.apache.org/log4net. -d On 2020/09/05 08:12:19, Ralph Goers wrote: OK, I’ve looked at http://logging.staged.apache.org/log4net. The download page still doesn’t look correct. The heading still says 2.0.8 although the source zip is 2.0.9 as it should be. The binary artifacts display as 2.0.8 but the links point to 2.0.9. Log4j controls all of this with a variable in the pom.xml file. Ralph On Sep 2, 2020, at 11:01 PM, Davyd McColl wrote: Ralph, I've updated apache/logging-log4net-site#asf-staging with the latest build artifacts from the apache/logging-log4net repo, please validate when you have time. Matt, I don't think I have access to push binary artifacts -- and, if I do, I don't know where (I'm quite sure Ralph did that for me last time, tho I'll need to understand better at some point so as to be less of a PITA); at least I understand now that the SVN repo for the logging site is deprecated and the new place I should be putting generated site material is as above (apache/logging-log4net-site#asf-staging) -d On 2020/09/02 17:01:15, Matt Sicker wrote: Subversion is still used for publishing release artifacts. The previous Subversion-based system for publishing the website itself has been migrated to git. Without using git-lfs, I don't see us migrating from svn to git for release distribution for quite some time (svn seems better suited for archiving binary files like that).
Re: [VOTE] Release Log4Net 2.0.9
Hi Ralph Sorry for wasting your time. I stupidly fixed up some of the the site in the SVN tree last time, and then re-generated before commiting to the github site, so it was still in a 1/2 state and I guess I was looking at the wrong thing in my browser when I checked ): I've updated again and validated that the *2.0.9* links point at the right place; pushed to asf-staging & checked on http://logging.staged.apache.org/log4net. -d On 2020/09/05 08:12:19, Ralph Goers wrote: OK, I’ve looked at http://logging.staged.apache.org/log4net. The download page still doesn’t look correct. The heading still says 2.0.8 although the source zip is 2.0.9 as it should be. The binary artifacts display as 2.0.8 but the links point to 2.0.9. Log4j controls all of this with a variable in the pom.xml file. Ralph > On Sep 2, 2020, at 11:01 PM, Davyd McColl wrote: > > Ralph, I've updated apache/logging-log4net-site#asf-staging with the latest > build artifacts from the apache/logging-log4net repo, please validate when > you have time. > > Matt, I don't think I have access to push binary artifacts -- and, if I do, I > don't know where (I'm quite sure Ralph did that for me last time, tho I'll > need to understand better at some point so as to be less of a PITA); at least > I understand now that the SVN repo for the logging site is deprecated and the > new place I should be putting generated site material is as above > (apache/logging-log4net-site#asf-staging) > > -d > > > On 2020/09/02 17:01:15, Matt Sicker wrote: > Subversion is still used for publishing release artifacts. The > previous Subversion-based system for publishing the website itself has > been migrated to git. Without using git-lfs, I don't see us migrating > from svn to git for release distribution for quite some time (svn > seems better suited for archiving binary files like that). >
Re: [VOTE] Release Log4Net 2.0.9
Ralph, I've updated apache/logging-log4net-site#asf-staging with the latest build artifacts from the apache/logging-log4net repo, please validate when you have time. Matt, I don't think I have access to push binary artifacts -- and, if I do, I don't know where (I'm quite sure Ralph did that for me last time, tho I'll need to understand better at some point so as to be less of a PITA); at least I understand now that the SVN repo for the logging site is deprecated and the new place I should be putting generated site material is as above (apache/logging-log4net-site#asf-staging) -d On 2020/09/02 17:01:15, Matt Sicker wrote: Subversion is still used for publishing release artifacts. The previous Subversion-based system for publishing the website itself has been migrated to git. Without using git-lfs, I don't see us migrating from svn to git for release distribution for quite some time (svn seems better suited for archiving binary files like that). On Wed, 2 Sep 2020 at 04:17, Davyd McColl wrote: > > I'm not following ): > > Previously, when I updated SVN, you said that it wasn't the way to do it. > > Is there a doc somewhere that someone new like me can follow for this? I'm > just wasting your time here. > > -d > On 2020/09/02 09:34:23, Apache wrote: > Unfortunately the staging and release locations for the release artifacts are > still using s not. But everything else is now in git. So in a release you > should publish the web site to the asf-staging branch of the site repo and > publish the artifacts to the dev location of the SVN dist repo. Once they are > approved they can be published. You should have permission to publish the web > site already. > > I will try to verify your changes tomorrow. > > Ralph > > > On Sep 1, 2020, at 11:11 PM, Davyd McColl wrote: > > > > Hi Ralph > > > > The missing tag is my fault -- I had a `rel/2.0.9` tag locally and > > obviously forgot to push with tags ): > > > > I've updated the source files for the site: > > - removed the mirror references > > - updated the links for 2.0.9 > > - updated the link to point to the html instead of the cgi > > > > I've also updated the README in the project to take out the dormant status > > commentary. > > > > Please review & update the live site if you're happy. > > > > Previously, as I understand it, the point of the SVN staging area was to > > provide built artifacts for the website. Since that's not in play any more, > > I was wondering how that's going to happen now? Someone will have to build > > before pushing. If you'd like, I could add the target folder that is built > > into git so that it's just a matter of copying files. > > > > I've also added an npm script around building the site, which checks if you > > have maven available & builds if possible -- perhaps this makes it easier > > for the next new person (: > > > > -d > > > > On 2020/09/02 05:20:50, Ralph Goers wrote: > > I also just noticed that the git repo has no tag to represent 2.0.9. > > Without a tag essentially there is no release. > > > > Ralph > > > >> On Aug 24, 2020, at 3:27 PM, Ralph Goers wrote: > >> > >> The release isn’t done yet. The web site still reflects 2.0.8. Release > >> announcements can’t be sent out until that is updated. > >> > >> Ralph > >> > >>>> On Aug 24, 2020, at 2:45 PM, Remko Popma wrote: > >>> > >>> Well done, everyone! > >>> > >>>> On Mon, Aug 24, 2020 at 10:43 PM Matt Sicker wrote: > >>> > >>>> Thanks again for managing the release! I’m sure you’ve just made a lot of > >>>> developers happy. :D > >>>> > >>>> On Mon, Aug 24, 2020 at 01:40 Davyd McColl wrote: > >>>> > >>>>> Ok, log4net 2.0.9 is up on nuget.org (: > >>>>> > >>>>> > >>>>> > >>>>> Thanks for all the help (: > >>>>> > >>>>> > >>>>> > >>>>> -d > >>>>> > >>>>> > >>>>> > >>>>> On 2020/08/23 19:13:36, Matt Sicker wrote: > >>>>> > >>>>> Yes, please go ahead and finish the release. The PMC approved this > >>>>> > >>>>> during our release vote. :) > >>>>> > >>>>> > >>>>> > >>>>> On Sun, 23 Aug 2020 at 10:22, Apache wrote: > >>>>> > >>>>>> > >>
Re: [VOTE] Release Log4Net 2.0.9
I'm not following ): Previously, when I updated SVN, you said that it wasn't the way to do it. Is there a doc somewhere that someone new like me can follow for this? I'm just wasting your time here. -d On 2020/09/02 09:34:23, Apache wrote: Unfortunately the staging and release locations for the release artifacts are still using s not. But everything else is now in git. So in a release you should publish the web site to the asf-staging branch of the site repo and publish the artifacts to the dev location of the SVN dist repo. Once they are approved they can be published. You should have permission to publish the web site already. I will try to verify your changes tomorrow. Ralph > On Sep 1, 2020, at 11:11 PM, Davyd McColl wrote: > > Hi Ralph > > The missing tag is my fault -- I had a `rel/2.0.9` tag locally and obviously > forgot to push with tags ): > > I've updated the source files for the site: > - removed the mirror references > - updated the links for 2.0.9 > - updated the link to point to the html instead of the cgi > > I've also updated the README in the project to take out the dormant status > commentary. > > Please review & update the live site if you're happy. > > Previously, as I understand it, the point of the SVN staging area was to > provide built artifacts for the website. Since that's not in play any more, I > was wondering how that's going to happen now? Someone will have to build > before pushing. If you'd like, I could add the target folder that is built > into git so that it's just a matter of copying files. > > I've also added an npm script around building the site, which checks if you > have maven available & builds if possible -- perhaps this makes it easier for > the next new person (: > > -d > > On 2020/09/02 05:20:50, Ralph Goers wrote: > I also just noticed that the git repo has no tag to represent 2.0.9. Without > a tag essentially there is no release. > > Ralph > >> On Aug 24, 2020, at 3:27 PM, Ralph Goers wrote: >> >> The release isn’t done yet. The web site still reflects 2.0.8. Release >> announcements can’t be sent out until that is updated. >> >> Ralph >> >>>> On Aug 24, 2020, at 2:45 PM, Remko Popma wrote: >>> >>> Well done, everyone! >>> >>>> On Mon, Aug 24, 2020 at 10:43 PM Matt Sicker wrote: >>> >>>> Thanks again for managing the release! I’m sure you’ve just made a lot of >>>> developers happy. :D >>>> >>>> On Mon, Aug 24, 2020 at 01:40 Davyd McColl wrote: >>>> >>>>> Ok, log4net 2.0.9 is up on nuget.org (: >>>>> >>>>> >>>>> >>>>> Thanks for all the help (: >>>>> >>>>> >>>>> >>>>> -d >>>>> >>>>> >>>>> >>>>> On 2020/08/23 19:13:36, Matt Sicker wrote: >>>>> >>>>> Yes, please go ahead and finish the release. The PMC approved this >>>>> >>>>> during our release vote. :) >>>>> >>>>> >>>>> >>>>> On Sun, 23 Aug 2020 at 10:22, Apache wrote: >>>>> >>>>>> >>>>> >>>>>> There can’t be. That is what the release vote was for. >>>>> >>>>>> >>>>> >>>>>> Ralph >>>>> >>>>>> >>>>> >>>>>>> On Aug 23, 2020, at 1:02 AM, Davyd McColl wrote: >>>>> >>>>>>> >>>>> >>>>>>> Thanks Dominik >>>>> >>>>>>> >>>>> >>>>>>> Are there any objections to me pushing the 2.0.9 package that had >>>> been >>>>> approved and uploaded to https://downloads.apache.org/logging/log4net/ >>>> to >>>>> nuget.org? >>>>> >>>>>>> >>>>> >>>>>>> -d >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>>> On August 23, 2020 09:59:02 Dominik Psenner wrote: >>>>> >>>>>>>> >>>>> >>>>>>>> Davyd, I added you as a collaborator. This should grant you the >>>>> privilege >>>>> >>>>>>>> to manage packages. You can now submit new and update or unlist >>>>> existing >>>>> >>>>>>>> packages
Re: [VOTE] Release Log4Net 2.0.9
Hi Ralph The missing tag is my fault -- I had a `rel/2.0.9` tag locally and obviously forgot to push with tags ): I've updated the source files for the site: - removed the mirror references - updated the links for 2.0.9 - updated the link to point to the html instead of the cgi I've also updated the README in the project to take out the dormant status commentary. Please review & update the live site if you're happy. Previously, as I understand it, the point of the SVN staging area was to provide built artifacts for the website. Since that's not in play any more, I was wondering how that's going to happen now? Someone will have to build before pushing. If you'd like, I could add the target folder that is built into git so that it's just a matter of copying files. I've also added an npm script around building the site, which checks if you have maven available & builds if possible -- perhaps this makes it easier for the next new person (: -d On 2020/09/02 05:20:50, Ralph Goers wrote: I also just noticed that the git repo has no tag to represent 2.0.9. Without a tag essentially there is no release. Ralph > On Aug 24, 2020, at 3:27 PM, Ralph Goers wrote: > > The release isn’t done yet. The web site still reflects 2.0.8. Release > announcements can’t be sent out until that is updated. > > Ralph > >> On Aug 24, 2020, at 2:45 PM, Remko Popma wrote: >> >> Well done, everyone! >> >> On Mon, Aug 24, 2020 at 10:43 PM Matt Sicker wrote: >> >>> Thanks again for managing the release! I’m sure you’ve just made a lot of >>> developers happy. :D >>> >>> On Mon, Aug 24, 2020 at 01:40 Davyd McColl wrote: >>> >>>> Ok, log4net 2.0.9 is up on nuget.org (: >>>> >>>> >>>> >>>> Thanks for all the help (: >>>> >>>> >>>> >>>> -d >>>> >>>> >>>> >>>> On 2020/08/23 19:13:36, Matt Sicker wrote: >>>> >>>> Yes, please go ahead and finish the release. The PMC approved this >>>> >>>> during our release vote. :) >>>> >>>> >>>> >>>> On Sun, 23 Aug 2020 at 10:22, Apache wrote: >>>> >>>>> >>>> >>>>> There can’t be. That is what the release vote was for. >>>> >>>>> >>>> >>>>> Ralph >>>> >>>>> >>>> >>>>>> On Aug 23, 2020, at 1:02 AM, Davyd McColl wrote: >>>> >>>>>> >>>> >>>>>> Thanks Dominik >>>> >>>>>> >>>> >>>>>> Are there any objections to me pushing the 2.0.9 package that had >>> been >>>> approved and uploaded to https://downloads.apache.org/logging/log4net/ >>> to >>>> nuget.org? >>>> >>>>>> >>>> >>>>>> -d >>>> >>>>>> >>>> >>>>>> >>>> >>>>>>> On August 23, 2020 09:59:02 Dominik Psenner wrote: >>>> >>>>>>> >>>> >>>>>>> Davyd, I added you as a collaborator. This should grant you the >>>> privilege >>>> >>>>>>> to manage packages. You can now submit new and update or unlist >>>> existing >>>> >>>>>>> packages. >>>> >>>>>>> >>>> >>>>>>> It would be great to have at least one other member of the pmc >>> listed >>>> as >>>> >>>>>>> administrator. The following documents the matrix of permissions. >>>> Note that >>>> >>>>>>> the amount of administrative tasks should be very limited: >>>> >>>>>>> >>>> >>>>>>> >>>> >>> https://docs.microsoft.com/en-us/nuget/nuget-org/organizations-on-nuget-org#managing-organization-members >>>> >>>>>>> >>>> >>>>>>> Cheers >>>> >>>>>>> -- >>>> >>>>>>> Sent from my phone. Typos are a kind gift to anyone who happens to >>>> find >>>> >>>>>>> them. >>>> >>>>>>> >>>> >>>>>>>> On Sat, Aug 22, 2020, 21:54 Davyd McColl wrote: >>>> >>>>>>>> >>>> >>>>>>>>
Re: Your project website
Matt I don't mind doing so - I'd just have to update the base download html file, if that's ok (and the download link on the main page as it points to the .cgi). Most of the download page exists "as-is", but I can see that there's placeholders for selecting mirrors. If I can simply replace those with direct linking (and probably take out the drop-down that allows selecting a different mirror), then that's no problem -- is that ok? -d On 2020/09/01 16:50:05, Matt Sicker wrote: You can link directly to https://downloads.apache.org/ as that site handles mirror redirects or CDN or whatever it’s implemented as right now. That CGI script is ancient and is no longer necessary as of, oh, many years I think? On Tue, Sep 1, 2020 at 01:17 Davyd McColl wrote: > Ralph, the log4net download link points to a cgi script; I've updated the > associated download_log4net.html as I think would be correct, but I'll only > know once it's run through the cgi script (which simply refers to an > external script, so doesn't really tell me what it does or expects). I > gather this is for setting up the mirror links. > > > > The latest download html is commited to subversion -- please try again? > > > > -d > > > > On 2020/09/01 05:01:45, Ralph Goers wrote: > > Yes, I thought I had checked them but I can confirm those 2 sites are > getting a 404. I have created > https://issues.apache.org/jira/projects/INFRA/issues/INFRA-20799 to get > some help determining what the problem might be. > > > > I have also created > https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Git+Hosted+Web+Site > to document editing the site and sub-projects. > > > > Ralph > > > > > On Aug 31, 2020, at 6:24 PM, Robert Middleton wrote: > > > > > > Something is funny with logging.apache.org - the links for log4cxx and > > > chainsaw lead to a 404 at the moment. I'm not sure if that's because > > > things are changing or if something else is messed up. > > > > > > I assume this means now that the site will be committed to git instead of > > > svn? > > > > > > -Robert Middleton > > > > > > On Mon, Aug 31, 2020 at 4:15 PM Ralph Goers > > > wrote: > > > > > >> The download link for Log4net is wrong even for the live site. For some > > >> reason it doesn’t seem it was updated during the release process. > > >> > > >> Ralph > > >> > > >>> On Aug 31, 2020, at 11:47 AM, Matt Sicker wrote: > > >>> > > >>> Looks good to me. The download link on the log4net page is broken, but > > >>> everything else looks good. > > >>> > > >>> On Mon, 31 Aug 2020 at 13:31, Ralph Goers > > >> > wrote: > > >>>> > > >>>> The logging site is now working properly. Please look at > > >> http://logging.staged.apache.org < > > >> http://logging.staged.apache.org/ >. > > >> I will not work on documenting this in Confluence. I know that not all > of > > >> the past log4j releases are in git yet. I will be taking care of that > soon. > > >> Please let me know if you see any other problems. > > >>>> > > >>>> Ralph > > >>>> > > >>>>> On Aug 30, 2020, at 10:21 PM, Ralph Goers > > >> wrote: > > >>>>> > > >>>>> Another follow-up. After a discussion on Slack with infra I > > >> determined that using GitHub pages isn’t what we want to do. I then > > >> modified the site to work with the normal “pub/sub” that infra supports > via > > >> the .asf.yaml files. The documentation for that says it supports having > > >> sub-projects be hosted in separate repos so I followed those > instructions. > > >> Unfortunately, those sites are not deploying. I have opened > > >> https://issues.apache.org/jira/browse/INFRA-20792 < > > >> https://issues.apache.org/jira/browse/INFRA-20792> to try to get this > > >> addressed but have not gotten a response to this yet nor to the > questions I > > >> asked on Slack. Not surprising since it was a Sunday afternoon. > > >>>>> > > >>>>> I have not documented the process yet since I am not sure I did > > >> everything correctly. > > >>>>> > > >>>>> FWIW, I plan to hold off starting the log4j release process until > this > > >> is resolve since trying to commit a new Log4j web site using svn has > b
Re: Your project website
Ralph, the log4net download link points to a cgi script; I've updated the associated download_log4net.html as I think would be correct, but I'll only know once it's run through the cgi script (which simply refers to an external script, so doesn't really tell me what it does or expects). I gather this is for setting up the mirror links. The latest download html is commited to subversion -- please try again? -d On 2020/09/01 05:01:45, Ralph Goers wrote: Yes, I thought I had checked them but I can confirm those 2 sites are getting a 404. I have created https://issues.apache.org/jira/projects/INFRA/issues/INFRA-20799 to get some help determining what the problem might be. I have also created https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Git+Hosted+Web+Site to document editing the site and sub-projects. Ralph > On Aug 31, 2020, at 6:24 PM, Robert Middleton wrote: > > Something is funny with logging.apache.org - the links for log4cxx and > chainsaw lead to a 404 at the moment. I'm not sure if that's because > things are changing or if something else is messed up. > > I assume this means now that the site will be committed to git instead of > svn? > > -Robert Middleton > > On Mon, Aug 31, 2020 at 4:15 PM Ralph Goers > wrote: > >> The download link for Log4net is wrong even for the live site. For some >> reason it doesn’t seem it was updated during the release process. >> >> Ralph >> >>> On Aug 31, 2020, at 11:47 AM, Matt Sicker wrote: >>> >>> Looks good to me. The download link on the log4net page is broken, but >>> everything else looks good. >>> >>> On Mon, 31 Aug 2020 at 13:31, Ralph Goers >> > wrote: The logging site is now working properly. Please look at >> http://logging.staged.apache.org < >> http://logging.staged.apache.org/ >. >> I will not work on documenting this in Confluence. I know that not all of >> the past log4j releases are in git yet. I will be taking care of that soon. >> Please let me know if you see any other problems. Ralph > On Aug 30, 2020, at 10:21 PM, Ralph Goers >> wrote: > > Another follow-up. After a discussion on Slack with infra I >> determined that using GitHub pages isn’t what we want to do. I then >> modified the site to work with the normal “pub/sub” that infra supports via >> the .asf.yaml files. The documentation for that says it supports having >> sub-projects be hosted in separate repos so I followed those instructions. >> Unfortunately, those sites are not deploying. I have opened >> https://issues.apache.org/jira/browse/INFRA-20792 < >> https://issues.apache.org/jira/browse/INFRA-20792> to try to get this >> addressed but have not gotten a response to this yet nor to the questions I >> asked on Slack. Not surprising since it was a Sunday afternoon. > > I have not documented the process yet since I am not sure I did >> everything correctly. > > FWIW, I plan to hold off starting the log4j release process until this >> is resolve since trying to commit a new Log4j web site using svn has been >> taking at least 30 minutes. My experience in committing the preview site to >> my personal GitHub site has shown that it is significantly faster. > > Ralph > >> On Aug 30, 2020, at 11:29 AM, Ralph Goers >> wrote: >> >> I have created the logging site in git at >> https://github.com/apache/logging-site < >> https://github.com/apache/logging-site>. I used jbake to generate the >> CMS portion of the site. It is pretty easy. All you have to do is >> >> cd sources >> Make the required changes >> mvn install >> >> You will then have a viewable site in the /docs directory and can >> view it by opening docs/index.html in the browser. >> >> I created a .asf.yaml file with the intention of having a preview >> site on the asf-staging branch and the live site at master. However, the >> instructions for the staging site seem to imply using pypubsub where I am >> attempting to use GitHub Pages for the live site. These seem to conflict as >> GitHub pages wants the site in the /docs directory while pypubsub seems to >> imply it needs to be in the root directory. >> >> I am able to get a site up at https://apache.github.io/logging-site < >> https://apache.github.io/logging-site> but it is not being reflected at >> https://logging.apache.org . >> >> At this point without clearer instructions from infra I am not sure >> where to go to make the site live. >> >> I have started a confluence page to document managing the site but it >> seems much easier than using the CMS. >> >> Ralph >> >> >> >>> On Aug 5, 2020, at 5:30 AM, Andrew Wetmore >> wrote: >>> >>> Hi: >>> >>> I am part of the Infrastructure team, and am writing to ask whether >> your >>> project is still using the Apache CMS for your project website. As >> you >>> know, the CMS is reaching end-of-life, and we need projects to move >>
Re: A little stuck with publishing updated site / docs for log4net 2.0.9
Thanks -d On 2020/08/28 16:07:45, Apache wrote: I will take care of the main logging site. It currently uses the ASF CMS but we have to get off of it so there isn’t much point in you having to learn how to deal with it. Ralph > On Aug 28, 2020, at 12:26 AM, Davyd McColl wrote: > > Hi all > > I've been trying to update content for http://logging.apache.org/log4net (in > particular http://logging.apache.org/log4net/release) and I'm sure I'm just > doing something silly or missing something. > > I've followed instructions at > https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site > up to point 7, which is where I'm stuck: I'm not sure where to find the > mentioned index.twig, mainly because I'm not sure what the document is > referring to with "main web site". I haven't found an index.twig in > https://svn.apache.org/repos/infra/websites/production/logging/content/ or > https://svn.apache.org/repos/asf/logging/site/cms/trunk, but it's wholly > possible I'm just missing it. Or that neither of these is the correct place > to look. > > I have updated documentation and committed via SVN for 2.0.9, including > updating the 2.x link. I haven't marked the project as "not dormant" (yet -- > I'll be more confident to do so once I've seen a complete release with all > the entailed bits, including this site, so that I have some semblance of > confidence to do it again!). All I've done is update the release notes to > include the changes for 2.0.9, which I'm sure some people might appreciate, > minor though the changes may be. > > Any assistance appreciated. I've already received much assistance from Ralph > and Matt (thanks!). > > -d
A little stuck with publishing updated site / docs for log4net 2.0.9
Hi all I've been trying to update content for http://logging.apache.org/log4net (in particular http://logging.apache.org/log4net/release) and I'm sure I'm just doing something silly or missing something. I've followed instructions at https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site up to point 7, which is where I'm stuck: I'm not sure where to find the mentioned index.twig, mainly because I'm not sure what the document is referring to with "main web site". I haven't found an index.twig in https://svn.apache.org/repos/infra/websites/production/logging/content/ or https://svn.apache.org/repos/asf/logging/site/cms/trunk, but it's wholly possible I'm just missing it. Or that neither of these is the correct place to look. I have updated documentation and committed via SVN for 2.0.9, including updating the 2.x link. I haven't marked the project as "not dormant" (yet -- I'll be more confident to do so once I've seen a complete release with all the entailed bits, including this site, so that I have some semblance of confidence to do it again!). All I've done is update the release notes to include the changes for 2.0.9, which I'm sure some people might appreciate, minor though the changes may be. Any assistance appreciated. I've already received much assistance from Ralph and Matt (thanks!). -d
Re: Log4Net Web site
Ralph, I've pushed to that PR with updated release notes based on what I could grok from prior commits, basically: - update to support netstandard2.0 & project restructuring - address LOG4NET-559 (adds null checks to prevent some reported issues with custom appenders) - address LOG4NET-563, which doesn't really affect the package release, looks like the commit was to update the site styling to be in line with log4j I only made the first listed change myself -- the others were largely due to the efforts of Stephan Bodewig and Dominik Psenner. -d On 2020/08/26 19:43:46, Davyd McColl wrote: Thanks Ralph I've figured out part of the problem: I updated the .gitignore as part of the build / maintenance update & the default gitignore rule for vs projects excludes folders called 'release', which left out release docs from the site. I've copied in from the develop branch and updated the gitignore so I can push them. I can see release notes now, so I'll scour the git log and see if I can make a reasonable attempt at release notes for 2.0.9 -d On 2020/08/26 19:30:26, Ralph Goers wrote: If you have moved them back I can take a look this evening when I have some time. Ralph > On Aug 26, 2020, at 10:22 AM, Davyd McColl wrote: > > I've raised a PR in the interim: all I've done is move the site assets back > where they belong (I inadvertently moved them out when refactoring for > build!). I have a lot to learn to understand what maven is doing, so right > now, I'm not very clued up as to why a lot of links in the generated output > (eg releases) are broken (target html is missing). For all I know, the > targets _should_ be missing? ie, they're maintained by hand? I dunno. > > -d > > On 2020/08/26 18:18:15, Davyd McColl wrote: > update: I have the site building with maven, but a _lot_ of the links are > broken (target html file is missing), so I'm going to have to hunt those > down. I'm also not sure how a changelog ends up in the site, since the > changes folder doesn't seem to e referenced (that I could find via a quick > text-search). > > I'll report back when I have something that works. > > -d > > On 2020/08/26 17:26:18, Davyd McColl wrote: > Thanks Ralph, will give that all a go tonight! > -d > > On August 26, 2020 17:24:40 Ralph Goers wrote: > Building the site should just require running > mvn site > in the home directory of the log4net project. To get it somewhere you can > view you can then do > mvn site:stage -DstagingDirectory=$HOME/log4net > Once you have a site you are happy with the instructions on the link Matt > gave you will tell you how to update the public site. > But first you have to get the site build working again. > Ralph > On Aug 26, 2020, at 8:17 AM, Ralph Goers wrote: > Actually, I can handle the main web site. I just need the Log4Net site > updated. From what I can tell it uses the Maven site plugin. That requires > files in the src/site and src/changes directory that were present in the > 2.0.8 release but seem to have been moved to src/Log4Net/site where they will > no longer work. > Ralph > On Aug 26, 2020, at 8:06 AM, Matt Sicker wrote: > I think these instructions are still up to date: > https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site > > [https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site] > On Wed, 26 Aug 2020 at 10:02, Davyd McColl wrote: > > > Ralph, I'm happy to -- but I have no idea how to. Even a pointer at a > document I can read on how would be greatly appreciated (ie how to get > content to the website) > -d > On 2020/08/26 16:54:46, Ralph Goers wrote: > Davyd, Can you update the web site? It still says Log4Net is dormant and does > not include any info about 2.0.0. The PMC is continuing to get queries since > there is no public info about the release. > Ralph > On Aug 24, 2020, at 3:31 PM, Ralph Goers wrote: > All the NuGet emails are forwarded to the Logging PMC. We are getting > requests to see the changes between 2.0.8 and 2.0.9. In the future I would > suggest we not push to NuGet until the web site is updated. To avoid this. > Ralph > -- > Matt Sicker
Re: Log4Net Web site
Thanks Ralph I've figured out part of the problem: I updated the .gitignore as part of the build / maintenance update & the default gitignore rule for vs projects excludes folders called 'release', which left out release docs from the site. I've copied in from the develop branch and updated the gitignore so I can push them. I can see release notes now, so I'll scour the git log and see if I can make a reasonable attempt at release notes for 2.0.9 -d On 2020/08/26 19:30:26, Ralph Goers wrote: If you have moved them back I can take a look this evening when I have some time. Ralph > On Aug 26, 2020, at 10:22 AM, Davyd McColl wrote: > > I've raised a PR in the interim: all I've done is move the site assets back > where they belong (I inadvertently moved them out when refactoring for > build!). I have a lot to learn to understand what maven is doing, so right > now, I'm not very clued up as to why a lot of links in the generated output > (eg releases) are broken (target html is missing). For all I know, the > targets _should_ be missing? ie, they're maintained by hand? I dunno. > > -d > > On 2020/08/26 18:18:15, Davyd McColl wrote: > update: I have the site building with maven, but a _lot_ of the links are > broken (target html file is missing), so I'm going to have to hunt those > down. I'm also not sure how a changelog ends up in the site, since the > changes folder doesn't seem to e referenced (that I could find via a quick > text-search). > > I'll report back when I have something that works. > > -d > > On 2020/08/26 17:26:18, Davyd McColl wrote: > Thanks Ralph, will give that all a go tonight! > -d > > On August 26, 2020 17:24:40 Ralph Goers wrote: > Building the site should just require running > mvn site > in the home directory of the log4net project. To get it somewhere you can > view you can then do > mvn site:stage -DstagingDirectory=$HOME/log4net > Once you have a site you are happy with the instructions on the link Matt > gave you will tell you how to update the public site. > But first you have to get the site build working again. > Ralph > On Aug 26, 2020, at 8:17 AM, Ralph Goers wrote: > Actually, I can handle the main web site. I just need the Log4Net site > updated. From what I can tell it uses the Maven site plugin. That requires > files in the src/site and src/changes directory that were present in the > 2.0.8 release but seem to have been moved to src/Log4Net/site where they will > no longer work. > Ralph > On Aug 26, 2020, at 8:06 AM, Matt Sicker wrote: > I think these instructions are still up to date: > https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site > > [https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site] > On Wed, 26 Aug 2020 at 10:02, Davyd McColl wrote: > > > Ralph, I'm happy to -- but I have no idea how to. Even a pointer at a > document I can read on how would be greatly appreciated (ie how to get > content to the website) > -d > On 2020/08/26 16:54:46, Ralph Goers wrote: > Davyd, Can you update the web site? It still says Log4Net is dormant and does > not include any info about 2.0.0. The PMC is continuing to get queries since > there is no public info about the release. > Ralph > On Aug 24, 2020, at 3:31 PM, Ralph Goers wrote: > All the NuGet emails are forwarded to the Logging PMC. We are getting > requests to see the changes between 2.0.8 and 2.0.9. In the future I would > suggest we not push to NuGet until the web site is updated. To avoid this. > Ralph > -- > Matt Sicker
Re: Log4Net Web site
I've raised a PR in the interim: all I've done is move the site assets back where they belong (I inadvertently moved them out when refactoring for build!). I have a lot to learn to understand what maven is doing, so right now, I'm not very clued up as to why a lot of links in the generated output (eg releases) are broken (target html is missing). For all I know, the targets _should_ be missing? ie, they're maintained by hand? I dunno. -d On 2020/08/26 18:18:15, Davyd McColl wrote: update: I have the site building with maven, but a _lot_ of the links are broken (target html file is missing), so I'm going to have to hunt those down. I'm also not sure how a changelog ends up in the site, since the changes folder doesn't seem to e referenced (that I could find via a quick text-search). I'll report back when I have something that works. -d On 2020/08/26 17:26:18, Davyd McColl wrote: Thanks Ralph, will give that all a go tonight! -d On August 26, 2020 17:24:40 Ralph Goers wrote: Building the site should just require running mvn site in the home directory of the log4net project. To get it somewhere you can view you can then do mvn site:stage -DstagingDirectory=$HOME/log4net Once you have a site you are happy with the instructions on the link Matt gave you will tell you how to update the public site. But first you have to get the site build working again. Ralph On Aug 26, 2020, at 8:17 AM, Ralph Goers wrote: Actually, I can handle the main web site. I just need the Log4Net site updated. From what I can tell it uses the Maven site plugin. That requires files in the src/site and src/changes directory that were present in the 2.0.8 release but seem to have been moved to src/Log4Net/site where they will no longer work. Ralph On Aug 26, 2020, at 8:06 AM, Matt Sicker wrote: I think these instructions are still up to date: https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site [https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site] On Wed, 26 Aug 2020 at 10:02, Davyd McColl wrote: Ralph, I'm happy to -- but I have no idea how to. Even a pointer at a document I can read on how would be greatly appreciated (ie how to get content to the website) -d On 2020/08/26 16:54:46, Ralph Goers wrote: Davyd, Can you update the web site? It still says Log4Net is dormant and does not include any info about 2.0.0. The PMC is continuing to get queries since there is no public info about the release. Ralph On Aug 24, 2020, at 3:31 PM, Ralph Goers wrote: All the NuGet emails are forwarded to the Logging PMC. We are getting requests to see the changes between 2.0.8 and 2.0.9. In the future I would suggest we not push to NuGet until the web site is updated. To avoid this. Ralph -- Matt Sicker
Re: Log4Net Web site
update: I have the site building with maven, but a _lot_ of the links are broken (target html file is missing), so I'm going to have to hunt those down. I'm also not sure how a changelog ends up in the site, since the changes folder doesn't seem to e referenced (that I could find via a quick text-search). I'll report back when I have something that works. -d On 2020/08/26 17:26:18, Davyd McColl wrote: Thanks Ralph, will give that all a go tonight! -d On August 26, 2020 17:24:40 Ralph Goers wrote: Building the site should just require running mvn site in the home directory of the log4net project. To get it somewhere you can view you can then do mvn site:stage -DstagingDirectory=$HOME/log4net Once you have a site you are happy with the instructions on the link Matt gave you will tell you how to update the public site. But first you have to get the site build working again. Ralph On Aug 26, 2020, at 8:17 AM, Ralph Goers wrote: Actually, I can handle the main web site. I just need the Log4Net site updated. From what I can tell it uses the Maven site plugin. That requires files in the src/site and src/changes directory that were present in the 2.0.8 release but seem to have been moved to src/Log4Net/site where they will no longer work. Ralph On Aug 26, 2020, at 8:06 AM, Matt Sicker wrote: I think these instructions are still up to date: https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site [https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site] On Wed, 26 Aug 2020 at 10:02, Davyd McColl wrote: Ralph, I'm happy to -- but I have no idea how to. Even a pointer at a document I can read on how would be greatly appreciated (ie how to get content to the website) -d On 2020/08/26 16:54:46, Ralph Goers wrote: Davyd, Can you update the web site? It still says Log4Net is dormant and does not include any info about 2.0.0. The PMC is continuing to get queries since there is no public info about the release. Ralph On Aug 24, 2020, at 3:31 PM, Ralph Goers wrote: All the NuGet emails are forwarded to the Logging PMC. We are getting requests to see the changes between 2.0.8 and 2.0.9. In the future I would suggest we not push to NuGet until the web site is updated. To avoid this. Ralph -- Matt Sicker
Re: Log4Net Web site
Thanks Ralph, will give that all a go tonight! -d On August 26, 2020 17:24:40 Ralph Goers wrote: Building the site should just require running mvn site in the home directory of the log4net project. To get it somewhere you can view you can then do mvn site:stage -DstagingDirectory=$HOME/log4net Once you have a site you are happy with the instructions on the link Matt gave you will tell you how to update the public site. But first you have to get the site build working again. Ralph On Aug 26, 2020, at 8:17 AM, Ralph Goers wrote: Actually, I can handle the main web site. I just need the Log4Net site updated. From what I can tell it uses the Maven site plugin. That requires files in the src/site and src/changes directory that were present in the 2.0.8 release but seem to have been moved to src/Log4Net/site where they will no longer work. Ralph On Aug 26, 2020, at 8:06 AM, Matt Sicker wrote: I think these instructions are still up to date: https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site On Wed, 26 Aug 2020 at 10:02, Davyd McColl wrote: Ralph, I'm happy to -- but I have no idea how to. Even a pointer at a document I can read on how would be greatly appreciated (ie how to get content to the website) -d On 2020/08/26 16:54:46, Ralph Goers wrote: Davyd, Can you update the web site? It still says Log4Net is dormant and does not include any info about 2.0.0. The PMC is continuing to get queries since there is no public info about the release. Ralph On Aug 24, 2020, at 3:31 PM, Ralph Goers wrote: All the NuGet emails are forwarded to the Logging PMC. We are getting requests to see the changes between 2.0.8 and 2.0.9. In the future I would suggest we not push to NuGet until the web site is updated. To avoid this. Ralph -- Matt Sicker
Re: Log4Net Web site
Thanks Matt, I'll give that a go tonight (: -d On 2020/08/26 17:07:00, Matt Sicker wrote: I think these instructions are still up to date: https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site On Wed, 26 Aug 2020 at 10:02, Davyd McColl wrote: > > Ralph, I'm happy to -- but I have no idea how to. Even a pointer at a > document I can read on how would be greatly appreciated (ie how to get > content to the website) > > -d > > On 2020/08/26 16:54:46, Ralph Goers wrote: > Davyd, Can you update the web site? It still says Log4Net is dormant and does > not include any info about 2.0.0. The PMC is continuing to get queries since > there is no public info about the release. > > Ralph > > > On Aug 24, 2020, at 3:31 PM, Ralph Goers wrote: > > > > All the NuGet emails are forwarded to the Logging PMC. We are getting > > requests to see the changes between 2.0.8 and 2.0.9. In the future I would > > suggest we not push to NuGet until the web site is updated. To avoid this. > > > > Ralph > > > > -- Matt Sicker
Re: log4net.dll - does 2.0.9 fix CVE-2018-1285
Hi Matt, I don't think that CVE is fixed in 2.0.9. I originally tracked down a commit in the develop branch which had the change in it, and I'm quite sure that commit was never brought into the 2.0.9 release. The changes I made on that branch were all around build, simply to try to get the project alive again. I noticed that the version had already been bumped to 2.0.9, so was ok with an initial resurrection release coming out with no further changes. I didn't know about this CVE until it was raised a little while ago, and I tracked down a matching commit in the develop branch. Last I remember, I proposed completing the 2.0.9 release with the dormant changes that were on the master branch as I forked, and that I would tackle this fix in 2.0.10 as soon as we got 2.0.9 out the door and I knew more about the release process. If I can figure out what I need to do to update the release site, that's (hopefully) the last piece of the puzzle, and I can get started on a quick 2.0.10 release which addresses the CVE. -d On 2020/08/26 17:05:06, Matt Sicker wrote: Yes, that release fixes the CVE. I still need to submit an update to Mitre about that. On Wed, 26 Aug 2020 at 09:52, #CircusLogic wrote: > > Team - > > The latest that I read about log4net.dll is that it is dormant as of 2017 and > the latest version was 2.0.8. > > But then I read that there is now a version 2.0.9. What is in 2.0.9? Is a fix > for CVE-2018-1285 included? > > Thanks, > CL -- Matt Sicker
Re: Log4Net Web site
Ralph, I'm happy to -- but I have no idea how to. Even a pointer at a document I can read on how would be greatly appreciated (ie how to get content to the website) -d On 2020/08/26 16:54:46, Ralph Goers wrote: Davyd, Can you update the web site? It still says Log4Net is dormant and does not include any info about 2.0.0. The PMC is continuing to get queries since there is no public info about the release. Ralph > On Aug 24, 2020, at 3:31 PM, Ralph Goers wrote: > > All the NuGet emails are forwarded to the Logging PMC. We are getting > requests to see the changes between 2.0.8 and 2.0.9. In the future I would > suggest we not push to NuGet until the web site is updated. To avoid this. > > Ralph >
Re: Log4net: Insecure site url on nuget
That's a good catch; the url should be updated (I'll put that on my TODO) and I'd raise that perhaps logging.apache.org should auto-redirect to https? -d On 2020/08/24 14:16:04, Dominik Psenner wrote: Hi, I noticed that the site url of the log4net nuget package is http instead of https (http://logging.apache.org/log4net/) and propose to update it. See: https://www.nuget.org/packages/log4net/ Best regards -- Sent from my phone. Typos are a kind gift to anyone who happens to find them.
Re: [VOTE] Release Log4Net 2.0.9
Ok, log4net 2.0.9 is up on nuget.org (: Thanks for all the help (: -d On 2020/08/23 19:13:36, Matt Sicker wrote: Yes, please go ahead and finish the release. The PMC approved this during our release vote. :) On Sun, 23 Aug 2020 at 10:22, Apache wrote: > > There can’t be. That is what the release vote was for. > > Ralph > > > On Aug 23, 2020, at 1:02 AM, Davyd McColl wrote: > > > > Thanks Dominik > > > > Are there any objections to me pushing the 2.0.9 package that had been > > approved and uploaded to https://downloads.apache.org/logging/log4net/ to > > nuget.org? > > > > -d > > > > > >> On August 23, 2020 09:59:02 Dominik Psenner wrote: > >> > >> Davyd, I added you as a collaborator. This should grant you the privilege > >> to manage packages. You can now submit new and update or unlist existing > >> packages. > >> > >> It would be great to have at least one other member of the pmc listed as > >> administrator. The following documents the matrix of permissions. Note that > >> the amount of administrative tasks should be very limited: > >> > >> https://docs.microsoft.com/en-us/nuget/nuget-org/organizations-on-nuget-org#managing-organization-members > >> > >> Cheers > >> -- > >> Sent from my phone. Typos are a kind gift to anyone who happens to find > >> them. > >> > >>> On Sat, Aug 22, 2020, 21:54 Davyd McColl wrote: > >>> > >>> Oh ok, well, mine is davydm (: > >>> > >>> -d > >>> > >>> > >>>> On August 22, 2020 20:49:59 Dominik Psenner wrote: > >>> > >>> > Apparently it cant be the email but must be the nuget accounts username, > >>> > apologies. > >>> > > >>> > -- > >>> > Sent from my phone. Typos are a kind gift to anyone who happens to find > >>> > them. > >>> > > >>> > On Sat, Aug 22, 2020, 20:39 Davyd McColl wrote: > >>> > > >>> >> I know I'm quite new, but I'm happy to push approved packages. My > >>> >> Microsoft > >>> >> account for nuget is this email address (dav...@gmail.com) > >>> >> > >>> >> -d > >>> >> > >>> >> > >>> >> On August 22, 2020 19:46:45 Dominik Psenner wrote: > >>> >> > >>> >> > Hi > >>> >> > > >>> >> > I recall that we were forced to transform the nuget account > >>> >> Apache.Logging ( > >>> >> > https://www.nuget.org/profiles/Apache.Logging) from a personal > >>> account > >>> >> into > >>> >> > an organization. I am currently the only member and administrator of > >>> that > >>> >> > organization. Please share with me (may also be in private) the nuget > >>> >> > account (most probably the email of your microsoft account) if you > >>> want > >>> >> me > >>> >> > to add you to the organization. Any member of the pmc may also become > >>> >> > administrator of that group if he wishes to. > >>> >> > > >>> >> > While I try to process your requests as fast as possible, please give > >>> me > >>> >> > some days. I am at the beach with the family and tend to swim and > >>> dive in > >>> >> > moments when I do not build sandcastles with the kids. ;-) > >>> >> > > >>> >> > Best regards > >>> >> > Dominik > >>> >> > -- > >>> >> > Sent from my phone. Typos are a kind gift to anyone who happens to > >>> find > >>> >> > them. > >>> >> > > >>> >> > On Sat, Aug 22, 2020, 02:01 Ralph Goers > >>> >> wrote: > >>> >> > > >>> >> >> And, FWIW, Nuget won’t let me register with my apache.org < > >>> >> >> http://apache.org/> email address saying it can’t be a work or > >>> school > >>> >> >> email. > >>> >> >> > >>> >> >> Ralph > >>> >> >> > >>> >> >> > On Aug 21, 2020, at 4:46 PM, Ralph Goers < > >>> ralph.go...@dslextreme.com> > >>> >> >>
Re: [VOTE] Release Log4Net 2.0.9
Thanks Dominik Are there any objections to me pushing the 2.0.9 package that had been approved and uploaded to https://downloads.apache.org/logging/log4net/ to nuget.org? -d On August 23, 2020 09:59:02 Dominik Psenner wrote: Davyd, I added you as a collaborator. This should grant you the privilege to manage packages. You can now submit new and update or unlist existing packages. It would be great to have at least one other member of the pmc listed as administrator. The following documents the matrix of permissions. Note that the amount of administrative tasks should be very limited: https://docs.microsoft.com/en-us/nuget/nuget-org/organizations-on-nuget-org#managing-organization-members Cheers -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Sat, Aug 22, 2020, 21:54 Davyd McColl wrote: Oh ok, well, mine is davydm (: -d On August 22, 2020 20:49:59 Dominik Psenner wrote: > Apparently it cant be the email but must be the nuget accounts username, > apologies. > > -- > Sent from my phone. Typos are a kind gift to anyone who happens to find > them. > > On Sat, Aug 22, 2020, 20:39 Davyd McColl wrote: > >> I know I'm quite new, but I'm happy to push approved packages. My >> Microsoft >> account for nuget is this email address (dav...@gmail.com) >> >> -d >> >> >> On August 22, 2020 19:46:45 Dominik Psenner wrote: >> >> > Hi >> > >> > I recall that we were forced to transform the nuget account >> Apache.Logging ( >> > https://www.nuget.org/profiles/Apache.Logging) from a personal account >> into >> > an organization. I am currently the only member and administrator of that >> > organization. Please share with me (may also be in private) the nuget >> > account (most probably the email of your microsoft account) if you want >> me >> > to add you to the organization. Any member of the pmc may also become >> > administrator of that group if he wishes to. >> > >> > While I try to process your requests as fast as possible, please give me >> > some days. I am at the beach with the family and tend to swim and dive in >> > moments when I do not build sandcastles with the kids. ;-) >> > >> > Best regards >> > Dominik >> > -- >> > Sent from my phone. Typos are a kind gift to anyone who happens to find >> > them. >> > >> > On Sat, Aug 22, 2020, 02:01 Ralph Goers >> wrote: >> > >> >> And, FWIW, Nuget won’t let me register with my apache.org < >> >> http://apache.org/> email address saying it can’t be a work or school >> >> email. >> >> >> >> Ralph >> >> >> >> > On Aug 21, 2020, at 4:46 PM, Ralph Goers < ralph.go...@dslextreme.com> >> >> wrote: >> >> > >> >> > This gets better and better. I was able to decrypt the file but the >> >> credentials don’t work. The Nuget.org <http://nuget.org/> site says >> >> “NuGet.org <http://nuget.org/> password login in no longer supported. >> >> Please use a Microsoft account to sign into NuGet gallery.” >> >> > >> >> > Ralph >> >> > >> >> >> On Aug 21, 2020, at 4:37 PM, Ralph Goers < ralph.go...@dslextreme.com >> > >> >> wrote: >> >> >> >> >> >> Going back through my old emails I see Dominik had the same problem >> in >> >> 2016. I forgot to update my files and now I see the instructions have >> >> changed. >> >> >> >> >> >> Ralph >> >> >> >> >> >>> On Aug 21, 2020, at 4:27 PM, Ralph Goers < >> ralph.go...@dslextreme.com> >> >> wrote: >> >> >>> >> >> >>> I figured out that the document is now at home.apache.org < >> >> http://home.apache.org/>. Unfortunately, that didn’t do me any good. >> gpg >> >> -d is failing with “No secret key”. That doesn’t seem too surprising >> since >> >> my key wasn’t used to sign the document. >> >> >>> >> >> >>> Ralph >> >> >>> >> >> >>>> On Aug 21, 2020, at 3:53 PM, Ralph Goers < >> ralph.go...@dslextreme.com> >> >> wrote: >> >> >>>> >> >> >>>> Dominik, >> >> >>>> >> >> >>>> The README file says that the keys can be found at >> >> https://peo
Re: [VOTE] Release Log4Net 2.0.9
Oh ok, well, mine is davydm (: -d On August 22, 2020 20:49:59 Dominik Psenner wrote: Apparently it cant be the email but must be the nuget accounts username, apologies. -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Sat, Aug 22, 2020, 20:39 Davyd McColl wrote: I know I'm quite new, but I'm happy to push approved packages. My Microsoft account for nuget is this email address (dav...@gmail.com) -d On August 22, 2020 19:46:45 Dominik Psenner wrote: > Hi > > I recall that we were forced to transform the nuget account Apache.Logging ( > https://www.nuget.org/profiles/Apache.Logging) from a personal account into > an organization. I am currently the only member and administrator of that > organization. Please share with me (may also be in private) the nuget > account (most probably the email of your microsoft account) if you want me > to add you to the organization. Any member of the pmc may also become > administrator of that group if he wishes to. > > While I try to process your requests as fast as possible, please give me > some days. I am at the beach with the family and tend to swim and dive in > moments when I do not build sandcastles with the kids. ;-) > > Best regards > Dominik > -- > Sent from my phone. Typos are a kind gift to anyone who happens to find > them. > > On Sat, Aug 22, 2020, 02:01 Ralph Goers wrote: > >> And, FWIW, Nuget won’t let me register with my apache.org < >> http://apache.org/> email address saying it can’t be a work or school >> email. >> >> Ralph >> >> > On Aug 21, 2020, at 4:46 PM, Ralph Goers >> wrote: >> > >> > This gets better and better. I was able to decrypt the file but the >> credentials don’t work. The Nuget.org <http://nuget.org/> site says >> “NuGet.org <http://nuget.org/> password login in no longer supported. >> Please use a Microsoft account to sign into NuGet gallery.” >> > >> > Ralph >> > >> >> On Aug 21, 2020, at 4:37 PM, Ralph Goers >> wrote: >> >> >> >> Going back through my old emails I see Dominik had the same problem in >> 2016. I forgot to update my files and now I see the instructions have >> changed. >> >> >> >> Ralph >> >> >> >>> On Aug 21, 2020, at 4:27 PM, Ralph Goers < ralph.go...@dslextreme.com> >> wrote: >> >>> >> >>> I figured out that the document is now at home.apache.org < >> http://home.apache.org/>. Unfortunately, that didn’t do me any good. gpg >> -d is failing with “No secret key”. That doesn’t seem too surprising since >> my key wasn’t used to sign the document. >> >>> >> >>> Ralph >> >>> >> >>>> On Aug 21, 2020, at 3:53 PM, Ralph Goers < ralph.go...@dslextreme.com> >> wrote: >> >>>> >> >>>> Dominik, >> >>>> >> >>>> The README file says that the keys can be found at >> https://people.apache.org/keys/group/logging-pmc.asc < >> https://people.apache.org/keys/group/logging-pmc.asc>. That url returns >> a 404. Any idea where it moved to? >> >>>> >> >>>> Ralph >> >>>> >> >>>>> On Aug 17, 2020, at 9:39 AM, Dominik Psenner >> wrote: >> >>>>> >> >>>>> I guess that would be a nuget publish. >> >>>>> >> >>>>> https://docs.microsoft.com/en-us/nuget/nuget-org/publish-a-package >> >>>>> >> >>>>> The credentials to that account are stored in the private repos of >> logging >> >>>>> pmc. Most members of the pmc should be in the set of recipients with >> their >> >>>>> gpg key. >> >>>>> -- >> >>>>> Sent from my phone. Typos are a kind gift to anyone who happens to >> find >> >>>>> them. >> >>>>> >> >>>>> On Mon, Aug 17, 2020, 08:56 Davyd McColl wrote: >> >>>>> >> >>>>>> Great! >> >>>>>> >> >>>>>> How do we get the nupkg to nuget.org? This is the final step that >> most >> >>>>>> users are going to be interested in. >> >>>>>> >> >>>>>> Having a look at what's at the url you posted, I have ideas on how >> to >> >>>>>> streamline future releases, so the next time I'm in that area, I'm >> >>&g
Re: [VOTE] Release Log4Net 2.0.9
I know I'm quite new, but I'm happy to push approved packages. My Microsoft account for nuget is this email address (dav...@gmail.com) -d On August 22, 2020 19:46:45 Dominik Psenner wrote: Hi I recall that we were forced to transform the nuget account Apache.Logging ( https://www.nuget.org/profiles/Apache.Logging) from a personal account into an organization. I am currently the only member and administrator of that organization. Please share with me (may also be in private) the nuget account (most probably the email of your microsoft account) if you want me to add you to the organization. Any member of the pmc may also become administrator of that group if he wishes to. While I try to process your requests as fast as possible, please give me some days. I am at the beach with the family and tend to swim and dive in moments when I do not build sandcastles with the kids. ;-) Best regards Dominik -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Sat, Aug 22, 2020, 02:01 Ralph Goers wrote: And, FWIW, Nuget won’t let me register with my apache.org < http://apache.org/> email address saying it can’t be a work or school email. Ralph > On Aug 21, 2020, at 4:46 PM, Ralph Goers wrote: > > This gets better and better. I was able to decrypt the file but the credentials don’t work. The Nuget.org <http://nuget.org/> site says “NuGet.org <http://nuget.org/> password login in no longer supported. Please use a Microsoft account to sign into NuGet gallery.” > > Ralph > >> On Aug 21, 2020, at 4:37 PM, Ralph Goers wrote: >> >> Going back through my old emails I see Dominik had the same problem in 2016. I forgot to update my files and now I see the instructions have changed. >> >> Ralph >> >>> On Aug 21, 2020, at 4:27 PM, Ralph Goers wrote: >>> >>> I figured out that the document is now at home.apache.org < http://home.apache.org/>. Unfortunately, that didn’t do me any good. gpg -d is failing with “No secret key”. That doesn’t seem too surprising since my key wasn’t used to sign the document. >>> >>> Ralph >>> >>>> On Aug 21, 2020, at 3:53 PM, Ralph Goers wrote: >>>> >>>> Dominik, >>>> >>>> The README file says that the keys can be found at https://people.apache.org/keys/group/logging-pmc.asc < https://people.apache.org/keys/group/logging-pmc.asc>. That url returns a 404. Any idea where it moved to? >>>> >>>> Ralph >>>> >>>>> On Aug 17, 2020, at 9:39 AM, Dominik Psenner wrote: >>>>> >>>>> I guess that would be a nuget publish. >>>>> >>>>> https://docs.microsoft.com/en-us/nuget/nuget-org/publish-a-package >>>>> >>>>> The credentials to that account are stored in the private repos of logging >>>>> pmc. Most members of the pmc should be in the set of recipients with their >>>>> gpg key. >>>>> -- >>>>> Sent from my phone. Typos are a kind gift to anyone who happens to find >>>>> them. >>>>> >>>>> On Mon, Aug 17, 2020, 08:56 Davyd McColl wrote: >>>>> >>>>>> Great! >>>>>> >>>>>> How do we get the nupkg to nuget.org? This is the final step that most >>>>>> users are going to be interested in. >>>>>> >>>>>> Having a look at what's at the url you posted, I have ideas on how to >>>>>> streamline future releases, so the next time I'm in that area, I'm >>>>>> definitely implementing those ideas. I don't see changes to the Release >>>>>> Notes area -- if I were to try to streamline that into a release, would a >>>>>> CHANGELOG file be useful? Or is there a better way? >>>>>> >>>>>> -d >>>>>> On 2020/08/16 23:26:07, Matt Sicker wrote: >>>>>> I committed them to dist already. I don't know how long we should wait >>>>>> for any mirroring to catch up, though on my end, I see updated >>>>>> artifacts on https://downloads.apache.org/logging/log4net/ other than >>>>>> the release notes. >>>>>> >>>>>> On Sun, 16 Aug 2020 at 15:09, Ralph Goers wrote: >>>>>>> >>>>>>> +1 to that! >>>>>>> >>>>>>> Let me know when these are published. I can update the web site to >>>>>> reflect that it is no longer dormant. >>>>>>> >>>>>>> Ralph >>>>>>> &
Re: [VOTE] Release Log4Net 2.0.9
I would imagine that this would have to either happen on Apache infra or be a GH action administered by someone with uber rights, though, yes, this is a good option. I don't have all the working pieces in my flows, but it would be convenient for my packages to have a similar mechanism, so if this is something the PMC would be interested in, I could play-test it against PeanutButter.* before proposing an automated solution? -d On August 17, 2020 20:07:34 Dominik Psenner wrote: Is there an option to trust a ci machine and automate the publish with a push of a tag after a successful vote? With this, anyone having the possibility to push a tag can forge a release with almost no effort. -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Mon, Aug 17, 2020, 19:21 Davyd McColl wrote: Correct, nuget publish. An option, once I'm trusted, is to allow me to publish. My nuget login is done via Microsoft credentials for dav...@gmail.com, and is secured by 2FA, so the only real risk is how dodgy I am (: If it's of interest to anyone, my profile is at https://www.nuget.org/profiles/davydm -d On August 17, 2020 18:46:50 Dominik Psenner wrote: > I guess that would be a nuget publish. > > https://docs.microsoft.com/en-us/nuget/nuget-org/publish-a-package > > The credentials to that account are stored in the private repos of logging > pmc. Most members of the pmc should be in the set of recipients with their > gpg key. > -- > Sent from my phone. Typos are a kind gift to anyone who happens to find > them. > > On Mon, Aug 17, 2020, 08:56 Davyd McColl wrote: > >> Great! >> >> How do we get the nupkg to nuget.org? This is the final step that most >> users are going to be interested in. >> >> Having a look at what's at the url you posted, I have ideas on how to >> streamline future releases, so the next time I'm in that area, I'm >> definitely implementing those ideas. I don't see changes to the Release >> Notes area -- if I were to try to streamline that into a release, would a >> CHANGELOG file be useful? Or is there a better way? >> >> -d >> On 2020/08/16 23:26:07, Matt Sicker wrote: >> I committed them to dist already. I don't know how long we should wait >> for any mirroring to catch up, though on my end, I see updated >> artifacts on https://downloads.apache.org/logging/log4net/ other than >> the release notes. >> >> On Sun, 16 Aug 2020 at 15:09, Ralph Goers wrote: >> > >> > +1 to that! >> > >> > Let me know when these are published. I can update the web site to >> reflect that it is no longer dormant. >> > >> > Ralph >> > >> > > On Aug 16, 2020, at 11:54 AM, Matt Sicker wrote: >> > > >> > > Thanks so much for your help in releasing this! >> > > >> > > On Sun, 16 Aug 2020 at 13:53, Davyd McColl wrote: >> > >> >> > >> I'll make changes to the automated build to affect all changes you >> have >> > >> made (and perhaps will make) automatically to future releases for the >> next >> > >> release. Apologies for making this more difficult than it needs to be >> (: >> > >> >> > >> -d >> > >> >> > >> >> > >> On August 16, 2020 20:37:01 Matt Sicker wrote: >> > >> >> > >>> Just a simple copy of the LICENSE and NOTICE file into the binaries >> > >>> zip, and a rename of the files to include "apache" in the name. I've >> > >>> uploaded them to dist along with updating the KEYS file for log4net, >> > >>> though that should probably be merged together with the project-wide >> > >>> KEYS file in the parent directory. There's an outdated README.html in >> > >>> the directory still containing the old release notes, but we can >> > >>> address that next. >> > >>> >> > >>> On Sun, 16 Aug 2020 at 13:12, Matt Sicker wrote: >> > >>>> >> > >>>> One issue I found in one of the artifacts that I can address before >> > >>>> uploading since it wasn't signed is the binaries zip is missing the >> > >>>> LICENSE file. I'm not sure if there's a standard way to include that >> > >>>> in the nupkg file, but I did see that in its metadata, it explicitly >> > >>>> says the code is Apache2 licensed at least. >> > >>>> >> > >>>> On Sun, 16 Aug 2020 at 13:03, Matt Sicker wrote: >> > >>>>> >> > >
Re: [VOTE] Release Log4Net 2.0.9
Correct, nuget publish. An option, once I'm trusted, is to allow me to publish. My nuget login is done via Microsoft credentials for dav...@gmail.com, and is secured by 2FA, so the only real risk is how dodgy I am (: If it's of interest to anyone, my profile is at https://www.nuget.org/profiles/davydm -d On August 17, 2020 18:46:50 Dominik Psenner wrote: I guess that would be a nuget publish. https://docs.microsoft.com/en-us/nuget/nuget-org/publish-a-package The credentials to that account are stored in the private repos of logging pmc. Most members of the pmc should be in the set of recipients with their gpg key. -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Mon, Aug 17, 2020, 08:56 Davyd McColl wrote: Great! How do we get the nupkg to nuget.org? This is the final step that most users are going to be interested in. Having a look at what's at the url you posted, I have ideas on how to streamline future releases, so the next time I'm in that area, I'm definitely implementing those ideas. I don't see changes to the Release Notes area -- if I were to try to streamline that into a release, would a CHANGELOG file be useful? Or is there a better way? -d On 2020/08/16 23:26:07, Matt Sicker wrote: I committed them to dist already. I don't know how long we should wait for any mirroring to catch up, though on my end, I see updated artifacts on https://downloads.apache.org/logging/log4net/ other than the release notes. On Sun, 16 Aug 2020 at 15:09, Ralph Goers wrote: > > +1 to that! > > Let me know when these are published. I can update the web site to reflect that it is no longer dormant. > > Ralph > > > On Aug 16, 2020, at 11:54 AM, Matt Sicker wrote: > > > > Thanks so much for your help in releasing this! > > > > On Sun, 16 Aug 2020 at 13:53, Davyd McColl wrote: > >> > >> I'll make changes to the automated build to affect all changes you have > >> made (and perhaps will make) automatically to future releases for the next > >> release. Apologies for making this more difficult than it needs to be (: > >> > >> -d > >> > >> > >> On August 16, 2020 20:37:01 Matt Sicker wrote: > >> > >>> Just a simple copy of the LICENSE and NOTICE file into the binaries > >>> zip, and a rename of the files to include "apache" in the name. I've > >>> uploaded them to dist along with updating the KEYS file for log4net, > >>> though that should probably be merged together with the project-wide > >>> KEYS file in the parent directory. There's an outdated README.html in > >>> the directory still containing the old release notes, but we can > >>> address that next. > >>> > >>> On Sun, 16 Aug 2020 at 13:12, Matt Sicker wrote: > >>>> > >>>> One issue I found in one of the artifacts that I can address before > >>>> uploading since it wasn't signed is the binaries zip is missing the > >>>> LICENSE file. I'm not sure if there's a standard way to include that > >>>> in the nupkg file, but I did see that in its metadata, it explicitly > >>>> says the code is Apache2 licensed at least. > >>>> > >>>> On Sun, 16 Aug 2020 at 13:03, Matt Sicker wrote: > >>>>> > >>>>> I'll sign and publish the artifacts today. > >>>>> > >>>>> On Mon, 3 Aug 2020 at 17:43, Ralph Goers wrote: > >>>>>> > >>>>>> Thanks Remko. That makes 3 +1 votes from PMC members. > >>>>>> > >>>>>> Ralph > >>>>>> > >>>>>>> On Aug 3, 2020, at 2:12 PM, Remko Popma wrote: > >>>>>>> > >>>>>>> +1 Remko. > >>>>>>> > >>>>>>> On Tue, Aug 4, 2020 at 1:04 AM Matt Sicker wrote: > >>>>>>> > >>>>>>>> +1 from me. We can handle the release signing afterwards as Ralph > >>>> suggests. > >>>>>>>> > >>>>>>>> On Mon, 3 Aug 2020 at 10:30, Ralph Goers > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Can other PMC members please review this? It has been more than 72 > >>>>>>>> hours. > >>>>>>>>> > >>>>>>>>> Ralph > >>>>>>>>> > >>>>>>>>>> On Jul 30, 2020, at 11:17 PM, Davyd McColl > >>>>>>>> wrote: > >>&g
Re: [VOTE] Release Log4Net 2.0.9
The nuget.org question is probably of the highest priority - that's how most people are going to get any .net package release. If it's not on nuget.org, it might as well not be released. Any idea who would know about releasing there? Is there someone I can bother? -d On August 17, 2020 18:08:15 Matt Sicker wrote: The release notes are generated from the README.html file in the dist area. I'm not sure where they're generated from, but some sort of changelog file to go alongside the artifacts could be helpful here. Otherwise, we'd typically only worry about the download links on the logging.apache.org site. As for nuget, I'm not sure about that. On Mon, 17 Aug 2020 at 01:56, Davyd McColl wrote: Great! How do we get the nupkg to nuget.org? This is the final step that most users are going to be interested in. Having a look at what's at the url you posted, I have ideas on how to streamline future releases, so the next time I'm in that area, I'm definitely implementing those ideas. I don't see changes to the Release Notes area -- if I were to try to streamline that into a release, would a CHANGELOG file be useful? Or is there a better way? -d On 2020/08/16 23:26:07, Matt Sicker wrote: I committed them to dist already. I don't know how long we should wait for any mirroring to catch up, though on my end, I see updated artifacts on https://downloads.apache.org/logging/log4net/ other than the release notes. On Sun, 16 Aug 2020 at 15:09, Ralph Goers wrote: > > +1 to that! > > Let me know when these are published. I can update the web site to reflect that it is no longer dormant. > > Ralph > > > On Aug 16, 2020, at 11:54 AM, Matt Sicker wrote: > > > > Thanks so much for your help in releasing this! > > > > On Sun, 16 Aug 2020 at 13:53, Davyd McColl wrote: > >> > >> I'll make changes to the automated build to affect all changes you have > >> made (and perhaps will make) automatically to future releases for the next > >> release. Apologies for making this more difficult than it needs to be (: > >> > >> -d > >> > >> > >> On August 16, 2020 20:37:01 Matt Sicker wrote: > >> > >>> Just a simple copy of the LICENSE and NOTICE file into the binaries > >>> zip, and a rename of the files to include "apache" in the name. I've > >>> uploaded them to dist along with updating the KEYS file for log4net, > >>> though that should probably be merged together with the project-wide > >>> KEYS file in the parent directory. There's an outdated README.html in > >>> the directory still containing the old release notes, but we can > >>> address that next. > >>> > >>> On Sun, 16 Aug 2020 at 13:12, Matt Sicker wrote: > >>>> > >>>> One issue I found in one of the artifacts that I can address before > >>>> uploading since it wasn't signed is the binaries zip is missing the > >>>> LICENSE file. I'm not sure if there's a standard way to include that > >>>> in the nupkg file, but I did see that in its metadata, it explicitly > >>>> says the code is Apache2 licensed at least. > >>>> > >>>> On Sun, 16 Aug 2020 at 13:03, Matt Sicker wrote: > >>>>> > >>>>> I'll sign and publish the artifacts today. > >>>>> > >>>>> On Mon, 3 Aug 2020 at 17:43, Ralph Goers wrote: > >>>>>> > >>>>>> Thanks Remko. That makes 3 +1 votes from PMC members. > >>>>>> > >>>>>> Ralph > >>>>>> > >>>>>>> On Aug 3, 2020, at 2:12 PM, Remko Popma wrote: > >>>>>>> > >>>>>>> +1 Remko. > >>>>>>> > >>>>>>> On Tue, Aug 4, 2020 at 1:04 AM Matt Sicker wrote: > >>>>>>> > >>>>>>>> +1 from me. We can handle the release signing afterwards as Ralph > >>>> suggests. > >>>>>>>> > >>>>>>>> On Mon, 3 Aug 2020 at 10:30, Ralph Goers > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Can other PMC members please review this? It has been more than 72 > >>>>>>>> hours. > >>>>>>>>> > >>>>>>>>> Ralph > >>>>>>>>> > >>>>>>>>>> On Jul 30, 2020, at 11:17 PM, Davyd McColl > >>>>>>>> wrote: > >>>>>>>>>> >
Re: [VOTE] Release Log4Net 2.0.9
Great! How do we get the nupkg to nuget.org? This is the final step that most users are going to be interested in. Having a look at what's at the url you posted, I have ideas on how to streamline future releases, so the next time I'm in that area, I'm definitely implementing those ideas. I don't see changes to the Release Notes area -- if I were to try to streamline that into a release, would a CHANGELOG file be useful? Or is there a better way? -d On 2020/08/16 23:26:07, Matt Sicker wrote: I committed them to dist already. I don't know how long we should wait for any mirroring to catch up, though on my end, I see updated artifacts on https://downloads.apache.org/logging/log4net/ other than the release notes. On Sun, 16 Aug 2020 at 15:09, Ralph Goers wrote: > > +1 to that! > > Let me know when these are published. I can update the web site to reflect > that it is no longer dormant. > > Ralph > > > On Aug 16, 2020, at 11:54 AM, Matt Sicker wrote: > > > > Thanks so much for your help in releasing this! > > > > On Sun, 16 Aug 2020 at 13:53, Davyd McColl wrote: > >> > >> I'll make changes to the automated build to affect all changes you have > >> made (and perhaps will make) automatically to future releases for the next > >> release. Apologies for making this more difficult than it needs to be (: > >> > >> -d > >> > >> > >> On August 16, 2020 20:37:01 Matt Sicker wrote: > >> > >>> Just a simple copy of the LICENSE and NOTICE file into the binaries > >>> zip, and a rename of the files to include "apache" in the name. I've > >>> uploaded them to dist along with updating the KEYS file for log4net, > >>> though that should probably be merged together with the project-wide > >>> KEYS file in the parent directory. There's an outdated README.html in > >>> the directory still containing the old release notes, but we can > >>> address that next. > >>> > >>> On Sun, 16 Aug 2020 at 13:12, Matt Sicker wrote: > >>>> > >>>> One issue I found in one of the artifacts that I can address before > >>>> uploading since it wasn't signed is the binaries zip is missing the > >>>> LICENSE file. I'm not sure if there's a standard way to include that > >>>> in the nupkg file, but I did see that in its metadata, it explicitly > >>>> says the code is Apache2 licensed at least. > >>>> > >>>> On Sun, 16 Aug 2020 at 13:03, Matt Sicker wrote: > >>>>> > >>>>> I'll sign and publish the artifacts today. > >>>>> > >>>>> On Mon, 3 Aug 2020 at 17:43, Ralph Goers wrote: > >>>>>> > >>>>>> Thanks Remko. That makes 3 +1 votes from PMC members. > >>>>>> > >>>>>> Ralph > >>>>>> > >>>>>>> On Aug 3, 2020, at 2:12 PM, Remko Popma wrote: > >>>>>>> > >>>>>>> +1 Remko. > >>>>>>> > >>>>>>> On Tue, Aug 4, 2020 at 1:04 AM Matt Sicker wrote: > >>>>>>> > >>>>>>>> +1 from me. We can handle the release signing afterwards as Ralph > >>>> suggests. > >>>>>>>> > >>>>>>>> On Mon, 3 Aug 2020 at 10:30, Ralph Goers > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Can other PMC members please review this? It has been more than 72 > >>>>>>>> hours. > >>>>>>>>> > >>>>>>>>> Ralph > >>>>>>>>> > >>>>>>>>>> On Jul 30, 2020, at 11:17 PM, Davyd McColl > >>>>>>>> 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 f
Re: [VOTE] Release Log4Net 2.0.9
I'll make changes to the automated build to affect all changes you have made (and perhaps will make) automatically to future releases for the next release. Apologies for making this more difficult than it needs to be (: -d On August 16, 2020 20:37:01 Matt Sicker wrote: Just a simple copy of the LICENSE and NOTICE file into the binaries zip, and a rename of the files to include "apache" in the name. I've uploaded them to dist along with updating the KEYS file for log4net, though that should probably be merged together with the project-wide KEYS file in the parent directory. There's an outdated README.html in the directory still containing the old release notes, but we can address that next. On Sun, 16 Aug 2020 at 13:12, Matt Sicker wrote: One issue I found in one of the artifacts that I can address before uploading since it wasn't signed is the binaries zip is missing the LICENSE file. I'm not sure if there's a standard way to include that in the nupkg file, but I did see that in its metadata, it explicitly says the code is Apache2 licensed at least. On Sun, 16 Aug 2020 at 13:03, Matt Sicker wrote: > > I'll sign and publish the artifacts today. > > On Mon, 3 Aug 2020 at 17:43, Ralph Goers wrote: > > > > Thanks Remko. That makes 3 +1 votes from PMC members. > > > > Ralph > > > > > On Aug 3, 2020, at 2:12 PM, Remko Popma wrote: > > > > > > +1 Remko. > > > > > > On Tue, Aug 4, 2020 at 1:04 AM Matt Sicker wrote: > > > > > >> +1 from me. We can handle the release signing afterwards as Ralph suggests. > > >> > > >> On Mon, 3 Aug 2020 at 10:30, Ralph Goers > > >> wrote: > > >>> > > >>> Can other PMC members please review this? It has been more than 72 > > >> hours. > > >>> > > >>> Ralph > > >>> > > >>>> On Jul 30, 2020, at 11:17 PM, Davyd McColl > > >> 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 > > >> > > > > > > > -- > Matt Sicker -- Matt Sicker -- Matt Sicker
Re: [ANNOUNCE] Welcome our new committer, Davyd McColl
Thanks. I hope to contribute more than just build infra in the near future. I'm looking forward to positively contributing to a project which has been a well-known stalwart of the .net community for many years. -d On August 4, 2020 21:27:15 Tim Sargent wrote: Congrats David! Tim On Tue, Aug 4, 2020 at 12:25 PM Matt Sicker wrote: Hi, It is my pleasure to announce to the community that Davyd McColl has joined our ranks. He made remarkable contributions to log4net working towards resurrecting the log4net community and making a new release, and we all believe he is a valuable member of Apache Logging Services now and in future. Please welcome aboard our newest committer! Kind regards, Matt Sicker VP Logging Services, ASF
Re: [VOTE] Release Log4Net 2.0.9
Having never signed release artifacts before, I'm likely to Do It Wrong. Is there any Signing For Dummies you could recommend to get going on the right foot? -d On August 2, 2020 21:31:43 Matt Sicker wrote: 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 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 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
Re: [VOTE] Release Log4Net 2.0.9
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 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
[VOTE] Release Log4Net 2.0.9
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
Re: [IMPORTANT] - Migration to ci-builds.a.o
Please let me know if I can help with that - if you're using the new build process I made and something doesn't work as expected, I'm happy to help. On July 18, 2020 02:58:03 Matt Sicker wrote: I've finished migrating all our jobs that I could find. There's a log4net pipeline that I could potentially enable in the new CI, but the Windows node doesn't seem to be working quite yet. On Thu, 16 Jul 2020 at 12:36, Matt Sicker wrote: Here’s the answer to my previous forward. I can look into this to make sure our builds are good there. -- Forwarded message - From: Gavin McDonald Date: Thu, Jul 16, 2020 at 11:33 Subject: [IMPORTANT] - Migration to ci-builds.a.o To: builds Hi All, This NOTICE is for everyone on builds.apache.org. We are migrating to a new Cloudbees based Client Master called https://ci-builds.apache.org. The migrations of all jobs needs to be done before the switch off date of 15th August 2020, so you have a maximum of 4 weeks. There is no tool or automated way of migrating your jobs, the differences in the platforms, the plugins and the setup makes it impossible to do in a safe way. So, you all need to start creating new jobs on ci-infra.a.o and then , when you are happy, turn off your old builds on builds.a.o. There are currently 4 agents over there ready to take jobs, plus a floating agent which is shared amongst many masters (more to come). I will migrate away 2 more agents from builds.a.o to ci-builds.a.o every few days, and will keep an eye of load across both and adjust accordingly. If needed, create a ticket on INFRA jira for any issues that crop up, or email here on builds@a.o. there may be one or two plugins we need to install/tweak etc. We will be not using 'Views' at the top level, but rather we will take advantage of 'Folders Plus' - each project will get its own Folder and have authorisation access to create/edit jobs etc within that folder. I will create these folders as you ask for them to start with. This setup allows for credentials isolation amongst other benefits, including but not limited to exclusive agents (Controlled Agents) for your own use , should you have any project targeted donations of agents. As with other aspects of the ASF, projects can choose to just enable all committers access to their folder, just ask. We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will not be setting up any forwarding rules or anything like that. So, please, get started *now *on this so you can be sure we are all completed before the final cutoff date of 15th August 2020. Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA tickets. Hadoop and related projects have their own migration path to follow, same cut off date, Cassandra, Beam, CouchDB have already migrated and are doing very well in their new homes. Lets get going ... -- *Gavin McDonald* Systems Administrator ASF Infrastructure Team -- Matt Sicker -- Matt Sicker
Re: [log4net] resurrection update
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
Re: [log4net] resurrection update
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
[log4net] resurrection update
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] CI server question
According to the documentation at CircleCI, this permission was required to enumerate repositories for users. However, AppVeyer is capable of doing so with a lesser permission, which I surmise may have been added after CircleCI first established their permissions. I've submitted an inquiry on that side. I've also submitted an inquiry to AppVeyer wrt their vs2019 build environment, which appears to be missing .net framework 3.5. -d On April 27, 2020 22:11:58 Matt Sicker wrote: Further info: https://issues.apache.org/jira/browse/INFRA-17133 https://issues.apache.org/jira/browse/INFRA-16927 https://issues.apache.org/jira/browse/INFRA-15964 https://issues.apache.org/jira/browse/INFRA-12197 On Mon, 27 Apr 2020 at 15:09, Matt Sicker wrote: According to past Infra tickets, CircleCI requires write access to our git repos, and that's not allowed at Apache. I have no idea if that limitation in CircleCI has ever been fixed. On Mon, 27 Apr 2020 at 14:55, Davyd McColl wrote: > > If supporting them can come at minimal or zero cost, I don't see why not. > As stated before, this is already achieved within CircleCI, so I guess now > it's up to either integrating that within Apache infra, or replicating > elsewhere. I'm checking out appveyer too. At some point, though, I'd really > appreciate some guidance into what direction(s) would be acceptable, before > I've tried every CI service available. > > -d > > > On April 27, 2020 21:44:29 Dominik Psenner wrote: > > > Mileage may vary, but I see no point in supporting ancient frameworks. > > Better support only few valuable targets well and offload maintenance > > efforts to whoever needs other targets that are hard to support. For > > instance, whoever builds against client profile could fork and build > > log4net from source. Patches to make it work are valuable and always > > welcome, now and anytime in the future. Those patches may not be mergable > > into develop/master either as they could live in their own branch if > > necessary. > > -- > > Sent from my phone. Typos are a kind gift to anyone who happens to find > > them. > > > > On Mon, Apr 27, 2020, 21:13 Davyd McColl wrote: > > > >> Thanks, I've already tried using mono for cross-compilation, but older > >> targets (and specifically client profile) make this option a bit of a > >> non-starter. I got it mostly working, but mostly isn't all the way. > >> > >> CircleCI provides a good build environment, which I'm probably going to > >> try > >> to replicate in docker, though that would still require a windows host. > >> > >> -d > >> > >> > >> On April 27, 2020 21:07:50 Dominik Psenner wrote: > >> > >> > As apache folks, we have the benefit of sponsored msdn subscriptions and > >> > thus some sponsored computing time in azure. May that be an option? > >> > > >> > I dont know about the tasks involved. > >> > > >> > I can also think of cross compiling on ubuntu inside docker by leveraging > >> > dotnet-sdk and linking against the reference assemblies shipped with mono > >> > or other requirements that can be provided with Dockerfile's, github > >> > actions or other build infrastructure. This [1] is a reference project > >> that > >> > works and may serve as a minimalistic sample that, to be honest, is pure > >> > net core/netstandard and therefore lacks mono. > >> > > >> > [1] https://github.com/dpsenner/event-sorcery > >> > -- > >> > Sent from my phone. Typos are a kind gift to anyone who happens to find > >> > them. > >> > > >> > On Mon, Apr 27, 2020, 16:48 Matt Sicker wrote: > >> > > >> >> Looks like AppVeyor is another option. Is that comparable to CircleCI? > >> >> > >> >> (For context, I'm mostly familiar with Jenkins as I work on that > >> >> project at $dayjob) > >> >> > >> >> On Mon, 27 Apr 2020 at 09:36, Matt Sicker wrote: > >> >> > > >> >> > Seems like I missed some other services: > >> >> https://infra.apache.org/services.html > >> >> > > >> >> > If nothing on there is appropriate, I think we need to create a Jira > >> >> > ticket in https://issues.apache.org/jira/browse/INFRA > >> >> > > >> >> > On Mon, 27 Apr 2020 at 01:28, Davyd McColl wrote: > >> >> > > > >> >> > > What would need to be done to make other CI systems talk with Apac
Re: [log4net] CI server question
If supporting them can come at minimal or zero cost, I don't see why not. As stated before, this is already achieved within CircleCI, so I guess now it's up to either integrating that within Apache infra, or replicating elsewhere. I'm checking out appveyer too. At some point, though, I'd really appreciate some guidance into what direction(s) would be acceptable, before I've tried every CI service available. -d On April 27, 2020 21:44:29 Dominik Psenner wrote: Mileage may vary, but I see no point in supporting ancient frameworks. Better support only few valuable targets well and offload maintenance efforts to whoever needs other targets that are hard to support. For instance, whoever builds against client profile could fork and build log4net from source. Patches to make it work are valuable and always welcome, now and anytime in the future. Those patches may not be mergable into develop/master either as they could live in their own branch if necessary. -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Mon, Apr 27, 2020, 21:13 Davyd McColl wrote: Thanks, I've already tried using mono for cross-compilation, but older targets (and specifically client profile) make this option a bit of a non-starter. I got it mostly working, but mostly isn't all the way. CircleCI provides a good build environment, which I'm probably going to try to replicate in docker, though that would still require a windows host. -d On April 27, 2020 21:07:50 Dominik Psenner wrote: > As apache folks, we have the benefit of sponsored msdn subscriptions and > thus some sponsored computing time in azure. May that be an option? > > I dont know about the tasks involved. > > I can also think of cross compiling on ubuntu inside docker by leveraging > dotnet-sdk and linking against the reference assemblies shipped with mono > or other requirements that can be provided with Dockerfile's, github > actions or other build infrastructure. This [1] is a reference project that > works and may serve as a minimalistic sample that, to be honest, is pure > net core/netstandard and therefore lacks mono. > > [1] https://github.com/dpsenner/event-sorcery > -- > Sent from my phone. Typos are a kind gift to anyone who happens to find > them. > > On Mon, Apr 27, 2020, 16:48 Matt Sicker wrote: > >> Looks like AppVeyor is another option. Is that comparable to CircleCI? >> >> (For context, I'm mostly familiar with Jenkins as I work on that >> project at $dayjob) >> >> On Mon, 27 Apr 2020 at 09:36, Matt Sicker wrote: >> > >> > Seems like I missed some other services: >> https://infra.apache.org/services.html >> > >> > If nothing on there is appropriate, I think we need to create a Jira >> > ticket in https://issues.apache.org/jira/browse/INFRA >> > >> > On Mon, 27 Apr 2020 at 01:28, Davyd McColl wrote: >> > > >> > > What would need to be done to make other CI systems talk with Apache >> Infra? >> > > >> > > I ask because I've spend around a day now trying to convince Travis CI >> to build log4net successfully, without a lot of joy, particularly because >> the Travis Windows build environment is quite out of date, having been >> launched as a beta service in 2018, with tooling from 2015. I can get >> vs2019 installed via chocolatey packages, which solves most of the >> requirements, but haven't had joy in getting .net 3.5 to install on the >> build machine yet, resulting in predictable build failures. In addition, >> the installation of vs2019 tooling adds a few minutes to build. >> > > >> > > In contrast, build at CircleCI has been simple, quick, and, best of >> all, works. I've also figured out artifact publishing, so, with the >> addition of some scripting, one possible solution might be for an Apache >> Jenkins build job to simply download the nuget package from CircleCI and >> publish it -- meaning that Apache nuget keys don't have to leave secure >> premises, which is a good thing (: For example, a parameterised build which >> is given only a build number could be manually kicked off when a release >> has been approved by all involved. This build could download the .nupkg >> from CircleCI and publish to nuget.org. >> > > >> > > If this (or something similar) seems like a viable option, I may be in >> a position to raise a PR (after cleaning up some git history -- I probably >> have 50 or 100 commits which are only attempts at getting TravisCI to build >> with varying approaches. >> > > >> > > -d >> > > On 2020-04-25 22:15:36, Matt Sicker wrote: >> > > The only external build systems that are
Re: [log4net] CI server question
Thanks, I've already tried using mono for cross-compilation, but older targets (and specifically client profile) make this option a bit of a non-starter. I got it mostly working, but mostly isn't all the way. CircleCI provides a good build environment, which I'm probably going to try to replicate in docker, though that would still require a windows host. -d On April 27, 2020 21:07:50 Dominik Psenner wrote: As apache folks, we have the benefit of sponsored msdn subscriptions and thus some sponsored computing time in azure. May that be an option? I dont know about the tasks involved. I can also think of cross compiling on ubuntu inside docker by leveraging dotnet-sdk and linking against the reference assemblies shipped with mono or other requirements that can be provided with Dockerfile's, github actions or other build infrastructure. This [1] is a reference project that works and may serve as a minimalistic sample that, to be honest, is pure net core/netstandard and therefore lacks mono. [1] https://github.com/dpsenner/event-sorcery -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Mon, Apr 27, 2020, 16:48 Matt Sicker wrote: Looks like AppVeyor is another option. Is that comparable to CircleCI? (For context, I'm mostly familiar with Jenkins as I work on that project at $dayjob) On Mon, 27 Apr 2020 at 09:36, Matt Sicker wrote: > > Seems like I missed some other services: https://infra.apache.org/services.html > > If nothing on there is appropriate, I think we need to create a Jira > ticket in https://issues.apache.org/jira/browse/INFRA > > On Mon, 27 Apr 2020 at 01:28, Davyd McColl wrote: > > > > What would need to be done to make other CI systems talk with Apache Infra? > > > > I ask because I've spend around a day now trying to convince Travis CI to build log4net successfully, without a lot of joy, particularly because the Travis Windows build environment is quite out of date, having been launched as a beta service in 2018, with tooling from 2015. I can get vs2019 installed via chocolatey packages, which solves most of the requirements, but haven't had joy in getting .net 3.5 to install on the build machine yet, resulting in predictable build failures. In addition, the installation of vs2019 tooling adds a few minutes to build. > > > > In contrast, build at CircleCI has been simple, quick, and, best of all, works. I've also figured out artifact publishing, so, with the addition of some scripting, one possible solution might be for an Apache Jenkins build job to simply download the nuget package from CircleCI and publish it -- meaning that Apache nuget keys don't have to leave secure premises, which is a good thing (: For example, a parameterised build which is given only a build number could be manually kicked off when a release has been approved by all involved. This build could download the .nupkg from CircleCI and publish to nuget.org. > > > > If this (or something similar) seems like a viable option, I may be in a position to raise a PR (after cleaning up some git history -- I probably have 50 or 100 commits which are only attempts at getting TravisCI to build with varying approaches. > > > > -d > > On 2020-04-25 22:15:36, Matt Sicker wrote: > > The only external build systems that are set up for Apache right now > > are Travis and some limited GitHub Action experiments. Other CI > > systems may need to talk with Apache Infra. > > > > On Sat, 25 Apr 2020 at 14:47, Davyd McColl wrote: > > > > > > Thanks for the reply (: > > > > > > Would external build systems like circleci be acceptable too? > > > > > > -d > > > > > > > > > > > > On April 25, 2020 21:03:01 Matt Sicker wrote: > > > > > > > Info about our existing infra is documented here: > > > > https://cwiki.apache.org/confluence/display/INFRA/Jenkins > > > > > > > > On Sat, 25 Apr 2020 at 13:38, Davyd McColl wrote: > > > >> > > > >> Hi > > > >> > > > >> Quick question: what operating system does the available CI server run? > > > >> Even if docker is an option, the host system is matters. > > > >> > > > >> Thanks > > > >> -d > > > >> > > > >> > > > > > > > > > > > > -- > > > > Matt Sicker > > > > > > > > > > > > -- > > Matt Sicker > > > > -- > Matt Sicker -- Matt Sicker
Re: [log4net] CI server question
What would need to be done to make other CI systems talk with Apache Infra? I ask because I've spend around a day now trying to convince Travis CI to build log4net successfully, without a lot of joy, particularly because the Travis Windows build environment is quite out of date, having been launched as a beta service in 2018, with tooling from 2015. I can get vs2019 installed via chocolatey packages, which solves most of the requirements, but haven't had joy in getting .net 3.5 to install on the build machine yet, resulting in predictable build failures. In addition, the installation of vs2019 tooling adds a few minutes to build. In contrast, build at CircleCI has been simple, quick, and, best of all, works. I've also figured out artifact publishing, so, with the addition of some scripting, one possible solution might be for an Apache Jenkins build job to simply download the nuget package from CircleCI and publish it -- meaning that Apache nuget keys don't have to leave secure premises, which is a good thing (: For example, a parameterised build which is given only a build number could be manually kicked off when a release has been approved by all involved. This build could download the .nupkg from CircleCI and publish to nuget.org. If this (or something similar) seems like a viable option, I may be in a position to raise a PR (after cleaning up some git history -- I probably have 50 or 100 commits which are only attempts at getting TravisCI to build with varying approaches. -d On 2020-04-25 22:15:36, Matt Sicker wrote: The only external build systems that are set up for Apache right now are Travis and some limited GitHub Action experiments. Other CI systems may need to talk with Apache Infra. On Sat, 25 Apr 2020 at 14:47, Davyd McColl wrote: > > Thanks for the reply (: > > Would external build systems like circleci be acceptable too? > > -d > > > > On April 25, 2020 21:03:01 Matt Sicker wrote: > > > Info about our existing infra is documented here: > > https://cwiki.apache.org/confluence/display/INFRA/Jenkins > > > > On Sat, 25 Apr 2020 at 13:38, Davyd McColl wrote: > >> > >> Hi > >> > >> Quick question: what operating system does the available CI server run? > >> Even if docker is an option, the host system is matters. > >> > >> Thanks > >> -d > >> > >> > > > > > > -- > > Matt Sicker > > -- Matt Sicker
Re: [log4net] CI server question
Thanks for the reply (: Would external build systems like circleci be acceptable too? -d On April 25, 2020 21:03:01 Matt Sicker wrote: Info about our existing infra is documented here: https://cwiki.apache.org/confluence/display/INFRA/Jenkins On Sat, 25 Apr 2020 at 13:38, Davyd McColl wrote: Hi Quick question: what operating system does the available CI server run? Even if docker is an option, the host system is matters. Thanks -d -- Matt Sicker
[log4net] CI server question
Hi Quick question: what operating system does the available CI server run? Even if docker is an option, the host system is matters. Thanks -d
Re: [Log4Net]: resurrection
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
[Log4Net]: resurrection
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
[Log4Net] resurrection update
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
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 >>&
Re: log4net: resurrection
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) log4n
Re: log4net: resurrection
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). > >>
Re: log4net: resurrection
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 n
Re: log4net: resurrection
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. >>>>>
Re: log4net: resurrection
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
Re: log4net: resurrection
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
log4net: resurrection
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. *
