Re: [VOTE] Release Rya (Incubating) version 3.2.10 RC3
+1 * Sig/Xsums OK, but you have no other signatures on your key to verify that the key used to sign these artifacts is actually your key, Aaron. Maybe you can find someone (in person or via phone) or who can your key for you? [1] * Verified that geoindexing is "off" * Cursory glance over dependencies getting bundled in shaded JARs and they look OK * Listed commit exists in the repo * L&N look correct for source release * DISCLAIMER present * Could build from source (`mvn package`) Overview on your website: * "Apache Rya (incubating) is a scalable RDF triple store built on top of a columnar index store (Accumulo)." Apache Accumulo®, please. * Required links are present to ASF * Incubator branding looks good (to my memory) * "Apache Rya (incubating)" is prominent too. Other things: * Noticed lots of warnings in your Maven project. Would be good to address this to reduce the likelihood of build issues by users. [2] * Nit: would be good to include when the 72hrs is "up" (with tz) instead of relying on the timestamp that the message landed in someone's inbox. * Got an error running a `mvn install` (since your dependency graph seems to be busted -- couldn't run a `mvn dependency:tree` without as I should be able to). [3] Rerunning it was fine the second time.. * Maintaining your shaded jars over time is probably a losing battle (if the licensing issues this time around weren't sign enough). I'd suggest you start putting some thought in how your source-release creates binaries that can be useful for people who want to run Rya but are not using the exact versions of all of the dependencies you're bundling for them. * I didn't inspect the JARs you're also distributing for licensing correctness. Will let this slide since for now :) - Josh [1] https://www.apache.org/dev/release-signing.html#web-of-trust [2] https://paste.apache.org/CQf3 [3] https://paste.apache.org/ssGd Aaron D. Mihalik wrote: I am pleased to be calling this vote for the source release of Apache Rya (Incubating), version 3.2.10. The source zip, including signatures, digests, etc. can be found at: https://dist.apache.org/repos/dist/dev/incubator/rya/rya-incubating-3.2.10-rc3/ Ancillary artifacts such as poms, jars, wars, ect. can be found here: https://repository.apache.org/content/repositories/orgapacherya-1004/org/apache/rya/rya-project/3.2.10-incubating/ The Git tag is rya-incubating-3.2.10-rc3 The Git commit ID is 66d8b7f060bddeeb7c50cb0918f98ce3b265c564 https://git-wip-us.apache.org/repos/asf?p=incubator-rya.git;a=commit;h=66d8b7f060bddeeb7c50cb0918f98ce3b265c564 Checksums of rya-project-3.2.10-source-release.zip: SHA1: 4468f55b9f381e9103ca1e2e9c25b30e1cad4ed0 MD5: a28d9a146857576903ff4fc3f7dae908 Release artifacts are signed with the following key: https://people.apache.org/keys/committer/mihalik.asc KEYS file available here: https://dist.apache.org/repos/dist/release/incubator/rya/KEYS Issues that were closed/resolved for this release are here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334209&styleName=Html&projectId=12319020 Issues resolved between RC1 and RC2 are here: https://issues.apache.org/jira/browse/RYA-184 Issues resolved between RC2 and RC3 are here: https://issues.apache.org/jira/browse/RYA-209 The vote will be open for 72 hours. Please download the release candidate and evaluate the necessary items including checking hashes, signatures, build from source, and test. The please vote: [ ] +1 Release this package as rya-project-3.2.10 [ ] +0 no opinion [ ] -1 Do not release this package because because...
Re: Move to Travis-CI?
(disclaimer, I really have no opinion at all about which system is used, just providing context) Aaron D. Mihalik wrote: Devs, We now have Jenkins (builds.apache.org) building master and all PRs. This is awesome, but I think we could do a bit more. How do you all feel about moving to Travis-CI? It seems like it'll give us more functionality than Jenkins, many other Apache projects use it, and it'll be more reliable than builds.apache.org. However, it'll require a special request to INFRA. Travis is not wholly more reliable than Jenkins on builds.a.o. If a build starts failing on Travis, you pretty much have no remediation at all. At least with Jenkins, you have some escalation because they are machines that the ASF controls. Specially, the purpose of moving to Travis-CI would be to gain more information about our code base, it's "health", and how PRs coming in may effect it. I think Travis-CI has a couple of key features: - Travis-CI builds all branches and PRs, and maintains all of the history (no artifacts) for those builds. Right now Jenkins will only retain the last few builds across all builds. This is kinda annoying if you want to investigate why an older PR failed. This might just be configuration on retention? You should have the karma to modify the job to change the number of jobs retained. Or someone with VP karma could grant it to you. Not sure if you have it wired up, but the ASF Jenkins can also be configured to build PRs and report back to GH. Not clear to me if you knew about that. - Travis-CI integrates with other tools (eg coveralls.io) that will allow us to track and explore other facets of our code (coveralls does code coverage). It seems like Apache supports coveralls, but there are other integrations (eg coverity scan) that might be useful as well. If a Jenkins plugin exists, INFRA can be bothered to try to get them to install it. INFRA may object depending on the stability of the plugin though. - Travis-CI provides a nice dashboard for looking at the build history for the project. What do you all think? I'm new to Travis-CI and many of these other tools, so if someone else has more experience, please chime in. Thanks, Aaron
