Gale asked what is needed to check before voting. I just realized that somehow my [DISCUSS] thread was not started, so here it is. (We'll try to keep only the actual VOTEs under the [VOTE] thread.)
First of all, if you know of a reason NOT to do a release, e.g. a critical security bug fix has not been included, then this would be the (last) time to scream out about that. :) However we hope to follow "Release early, release often" - so it's OK if there are known bugs in the release candidate - we are not going to wait for a perfect day. As a minimum you should download (at least one of) the source-release.zip and check that they build on your set up. The build must be verified on a "machine you control" - e.g. typically that you have admin privileges. The README should say which Java and Maven version you need - in a way that is part of the checking as well (the previous release wrongly said you needed Java 7 when it only worked with Java 8). You don't need to test their functionality - in fact testing the taverna-osgi API beyond the unit tests would require you to develop another command line application! In Apache Taverna I think we agree we want all the unit tests to pass for a release to be OK, so don't use -DskipTests=true and just make sure it says SUCCESS at the end of building. If you like you can test the command line tools, like in this case tavlang, according to its README. There should be example workflows under taverna-scufl2-examples/ -- a new bug discovered should not be a show-stopper, but "Does not start at all on Windows" probably should be a show-stopper. As PPMC members we also need to check that we are not releasing files that can't be part of an Apache release - basically the red warning flags are: * Binary files inside source archive (e.g. pictures, ZIP files, JARs) * Files with missing /** Apache */ headers * Anything that says GNU or GPL - including in dependencies * Files that say (c) someoneElse (or have another license, e.g. BSD) - but isn't listed in the NOTICE or LICENSE file I am not sure if all PPMC members are required to check these things before voting, or if it's enough that one of them does.. Mentors? Luckily we're using Maven which has a a 'rat' plugin, that can check almost all of these things. You can run mvn apache-rat:check - and it would fall over if something is wrong. Example of error: [ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.11:check (default-cli) on project apache-taverna-engine: Too many files with unapproved license: 136 See RAT report in: /home/stain/src/taverna/incubator-taverna-engine/target/rat.txt -> [Help 1] The way we use it that we add 'excludes' to RAT for the files that at first instance flags a warning with RAT, but that have been checked. See https://github.com/apache/incubator-taverna-language/blob/master/pom.xml#L60 An eager reviewer would even go the extra mile and go through this exclude list to see if it's true, e.g. that roterms.ttl with Creative Commons is actually mentioned in our LICENSE or NOTICE file, as in https://github.com/apache/incubator-taverna-language/blob/master/LICENSE#L365 It's important that someone verifies that the checksums are true - e.g. that the md5 or sha1 checksums of the files match what is in the email - otherwise we don't agree on what we are voting over to publish. On Linux/OS X you can use 'md5sum' or 'sha1sum' command line tools - on Windows you would need to install additional tools. Similarly the PGP/GPG signature must match one of the keys in our official KEYS file https://www.apache.org/dist/incubator/taverna/KEYS -- to verify the PGP signatures, see http://www.apache.org/info/verification.html Another check that I like to do (which I don't think is required) is to verify that the git commit mentioned match the content of the source code archive. This is easiest achieved by also cloning from git and do 'git checkout' the git commit ID in the email, e.g. git checkout 55558801670d5fec9cea6e242ca3ad8f17bf9fbf .. and then move the .git folder into the unpacked source-release.zip folder . After this, "git status" should tell you if any files differ. There might be the odd generated file (like DEPENDENCIES) that don't match, but it should not mismatch in any of the source code files. If you are paranoid, also inspect .gitignore :)) This basically verifies that the release manager has not accidentally introduced files that are not checked in. As we are using the "mvn release" for making the RC, yhis is already double-checked by Maven - but it's good to check now and then - don't trust the computer! -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
