Thank you for the excellent information, Stian. Apologies for using the wrong thread before!
On Fri, Feb 19, 2016, 3:57 AM Stian Soiland-Reyes <[email protected]> wrote: > 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 >
