Hi again Christofer, I'm afraid I replied too soon, so let me get to the details which you had included in postscript (which I failed to notice :)).
And thankyou very much for the review !!! [...] > > [FAILED] Download all staged artifacts under the url specified in the > release vote email. This confuses me, I am able to obtain them right now with wget: wget https://files.pythonhosted.org/packages/3a/cc/c5ae68441f8ce2e2cb056b291e7d20181a18d8545e2993161f68d0f2a07c/BuildStream-1.95.3.dev0.tar.gz > No signed artifacts, downloaded zip package from GitHub, no > signatures or hashes Ok I see there is a desire for a gpg signature, it is not entirely clear that this is required from the policy at the proposal stage: "All supplied packages MUST be cryptographically signed by the Release Manager with a detached signature. Folks who vote +1 for release MAY offer their own cryptographic signature to be concatenated with the detached signature file (at the Release Manager's discretion) prior to release." I'm reading that published release artifacts MUST be signed, and that eligible voters in the voting stage MAY provide a signature. FWIW, all of our release tags (internal or external) are signed tags, and in any case I can surely provide a signature of the tarball(s) in the next candidate proposal. > [FAILED] Verify the signature is correct. > No signature Right. > [FAILED] Check if the signature references an Apache email address. > No signature I don't see any requirement for that in the policy, is this somehow a requirement ? > [FAILED] Verify the SHA512 hashes. > No hashes I did provide the sha256 hashes which appear correct, again I'm not seeing anything about this in the policy. > [OK] Unzip the archive. > [OK] Verify the existence of LICENSE, NOTICE files in the extracted > source bundle. > [MINOR] Verify the content of LICENSE, NOTICE files in the extracted > source bundle. > Notice references 2021 and not 2022 > [FAILED] [RM] Run RAT externally to ensure there are no surprises. > MANY files without Apache headers at all (Searching for > http://www.apache.org/licenses/LICENSE-2.0 in the doc folder only > brought one result at all, even in the tests directory there are > Apache headers only on a few files) There are configuration YAML files which related to default configuration for plugins, for instance: https://github.com/apache/buildstream-plugins/blob/master/src/buildstream_plugins/elements/autotools.yaml It is our policy to never clutter these files with license statements, as these are litterally used in place to produce user facing documentation: https://apache.github.io/buildstream-plugins/elements/autotools.html It would detract readability of our user facing documentation to clutter these configuration files with license headings, and it would be much worse to duplicate the configuration data in the docs (as we would no longer have the guarantee that the docs tell the absolute truth). > The list of non-approved license headers is 2078 lines/files long > There are binary files in there: While I would call the ODG files > sort of ok (OpenDocument Graphic File), the test contain archives > which we generally don't like to see > doc/bst2html.py is an MIT licensed file not mentioned in the LICENSE > file As per section 4 (Redistribution) of the license: https://www.apache.org/licenses/LICENSE-2.0 It is my understanding that such derivative works must be listed in the NOTICE file, which `doc/bst2html.py` is certainly mentioned. As is mentioned the copied/derived work at `src/buildstream/_frontend/complete.py` The odg files are of course so that we never include rendered graphics/diagrams in our documentation without revisioning the sources used to generate these graphics directly adjacent. The tarballs are extremely lightweight are are only included as data to run tests against (they are essentially hello world programs, or just tarballs which contain data that tests expect). Is there anything concrete we need to do here ? > The used Apache headers in generally all files are non-standard > headers, which contain Copyright information to “Copyright (C) 2018 > Codethink Limited”) See here to how they should look like: > https://www.apache.org/legal/src-headers.html It would seem that the following had escaped us: https://www.apache.org/legal/src-headers.html#headers Specifically: "note that there should be no copyright notice in the header." Although I wonder how important this is given the lower case "should" (as opposed to "MUST")... and perhaps this is acceptable if added to the NOTICE file in some way (as seems to be indicated by the following): > [FAILED] Search for Copyright references, and if they are in headers, > make sure these files containing them are mentioned in the LICENSE > file. > There’s code with Copyright headers for (All of these in various > flavors), none of which are mentioned anywhere (NOTICE, LICENSE): > - Copyright (C) 2019 Bloomberg Finance L.P. > - Copyright (C) 2017 Codethink Limited > - Copyright (c) 2014 by Armin Ronacher. > - Copyright 2020 The Bazel Authors. > - Copyright (c) 2015, Google Inc. > - Copyright 2018 Google LLC > Right, these are all very easy to account for, but I could use some guidance as to how precisely to update the NOTICE file for this. It would strike me as very odd to modify the LICENSE file, as I think anyone would expect the LICENSE file to contain the unmodified text from: https://www.apache.org/licenses/LICENSE-2.0.txt Best Regards, -Tristan
