Kam posted artifacts for 0.8.1 RC0 and asked me to take a look at them. Here are my notes:
- I imported the KEYS file but then failed to find the signing key. gpg --verify gearpump-0.8.1-incubating-src.tgz.asc gearpump-0.8.1-incubating-src.tgz gpg: Signature made Fri 24 Jun 2016 03:07:40 PM PDT using RSA key ID E7DE27E3 gpg: Can't check signature: public key not found - recv-key E7DE27E3 worked gpg: key E7DE27E3: public key "Kam Kasravi (CODE SIGNING KEY) < [email protected]>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) - And now the signature check passes gpg: Signature made Fri 24 Jun 2016 03:07:40 PM PDT using RSA key ID E7DE27E3 gpg: Good signature from "Kam Kasravi (CODE SIGNING KEY) < [email protected]>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 4FF1 FDB7 1079 F43F 132D FBBB 5806 2555 E7DE 27E3 I encourage Kam and everyone to go to an ApacheCon or the meetups of other projects and get your keys signed by other Apache folks. Yes, I should take my own advice... my code signing key has the same issue. - MD5 and SHA1 checksum files match file sums - Archive unpacks and layout looks good - LICENSE file looks ok, except maybe the text of the SIL Open Font License is missing? - Is the NOTICE file complete? "If the dependency supplies a NOTICE file, its contents must be analyzed and the relevant portions bubbled up into the top-level NOTICE file." (http://www.apache.org/dev/licensing-howto.html) We don't want to add anything here not legally required, though. I'm assuming you went through all of your dependencies and checked if they have anything in a NOTICE file? If not let's do that. - I can't find build instructions on the website (eg. http://gearpump.incubator.apache.org/how-to-contribute.html). They are in the README.md, however. How does one invoke 'sbt' such that it will also run the Apache RAT tool? - What is http://dl.bintray.com/fvunicorn/maven/org/apache/gearpump/gearpump-shaded-gs-collections/6.2.0/gearpump-shaded-gs-collections-6.2.0.jar ? I'm not sure this will be fatal to the release candidate but this is something that needs to be fixed. At the least it should be hosted on Apache infrastructure somewhere. Ideally, the shading and staging of gs-collections can be made part of the build so no need for a custom artifact of gs-collections just for gearpump. Same for gearpump-shaded-akka-kyro and anything like this I may have missed. - Some code builds against a downstream commercial derivative of an Apache project, hosted on a third party repository. You should not be doing this. If you depend on Hadoop, build against an Apache released version of Hadoop. When ready to start a release candidate vote, Mnemonic recently ran a vote, you can use that as an example. Vote thread: https://s.apache.org/NqCu Result: https://s.apache.org/wERS
