Yeah, we can develop it in the wiki, or append it to http://taverna.incubator.apache.org/community/releasing perhaps?
There should be a "I received a VOTE email, what do I do now?" section. On 2 March 2016 at 11:59, Ian Dunlop <[email protected]> wrote: > Hello, > > I think we need to capture all these tricks somewhere. Stian suggested we > propose updating the 'official' apache release page - sounds like a good > idea - but I think we could add it to the taverna pages first and then > maybe send a link to it to the (I don't know) incubator list to gauge > interest. > > Cheers, > > Ian > > On 1 March 2016 at 22:42, Gale Naylor <[email protected]> wrote: > >> Thank you, Stian! Some of my questions I figured out today, but some I did >> not, so I very much appreciate the hints and instructions. >> >> >> On Tue, Mar 1, 2016 at 2:28 PM Stian Soiland-Reyes <[email protected]> >> wrote: >> >> > Thanks for reviewing! >> > >> > >> > > (1) How do I verify that the commit id in the downloaded files matches >> > that >> > > in the VOTE email? (I've looked on the internet, but have yet to find >> > > anything helpful.) >> > >> > I don't think most people check this deeply.. but I guess at least one >> > voter should. >> > >> > Here's what I do: >> > >> > mkdir 1 ; cd 1 # new folder >> > git clone that-repository >> > git checkout that-commit-id-from-the-email-asdfjaskdjfsakjdfksajdf >> > rm -rf * >> > unzip ../the-release-candidate.zip >> > mv apache-taverna-*/* . (one level up) >> > git status >> > >> > Git will then check the checksums of every file and let you know what >> > has 'changed' (as it would believe you have edited it). >> > >> > >> > Here's another way that doesn't require using the 'git' command: >> > >> > Download the git commit corresponding to the email by browsing for it on >> > GitHub: >> > >> > >> > >> https://github.com/apache/incubator-taverna-language/tree/66866a5454ed23262c055f65155d7a195c68a17d >> > Click "Download ZIP" >> > >> > mkdir 1 ; cd 1 >> > unzip ../66866a5454ed23262c055f65155d7a195c68a17d.zip >> > >> > cd ../ ; mkdir 2 ; cd 2 >> > unzip release-candidate.zip >> > >> > cd .. >> > diff -uR 1 2 >> > >> > The files that differ (and their differences!) will be shown. >> > >> > Make sure you don't have any target/ folders before diff-ing (run mvn >> > clean to be sure) >> > >> > If you do the above with a git clone instead - remember that the zip >> > doesn't include the .git/ folder - so you would have to delete the >> > checked out .git folder before diffing. (Don't do this on your >> > regular checkout as you would lose all local branches!) >> > >> > >> > >> > > (2) Are the "binary artifacts" in the target folders? Which files are >> > > considered "binary artifacts?" >> > >> > Well, the target/ files are binary artifacts, but they (should) have >> > been made by your build on your machine - not be part of the source >> > ZIP. >> > >> > >> > One thing to look out for is in the downloaded source ZIP that there >> > are no unexpected binary artifacts in it *before you build* - e.g. >> > there should not be any *.jars in there. (The source distribution >> > should be 'clean'). We do have some *expected* binaries, pictures and >> > test workflows for instance. As those can't have license headers they >> > should be declared in NOTICE/LICENSE if they came from third-parties. >> > (E.g. if we used a Creative Commons-licensed JPEG picture) >> > >> > >> > In terms of release candidate, the binaries would be installers and >> > JARs etc., under >> > https://dist.apache.org/repos/dist/dev/incubator/taverna/binaries/ >> > (But there are none for this release candidate) >> > >> > ..in addition to the JARs that have been staged to the Maven repository >> > >> > >> https://repository.apache.org/content/repositories/orgapachetaverna-1011/org/apache/taverna/ >> > >> > >> > > (3) How do I verify that the build produces the binaries? By visual >> > > inspection? What am I looking for? >> > >> > >> > As for checking the Maven repository, if you want to do it really >> > proper you should check that all the JARs that are staged can be built >> > from the downloaded release candidate ZIP - e.g. that your target/ >> > folder contains all of the same ones. If I do this, I do a recursive >> > wget of the repository, and then compare the result of "find . -name >> > '*jar'" in the wget-tree with */*/target/*.jar. I don't think most >> > people do this. >> > >> > Paranoid-mode would be to download each JAR and check that they only >> > have the same *.class files - but these would differ for every build >> > and so can't be compared any further without lots of clever tooling - >> > so nobody does this. (I think there should be an Apache-hosted tool or >> > Maven plugin that could do this). >> > >> > >> > Practically the best is just to click briefly into the repository in a >> > browser and see there are not any 'additional' folders that shouldn't >> > be there, e.g. we are now voting on taverna-maven-parent, taverna-osgi >> > and taverna-language, and so we should not see >> > org/apache/taverna/engine in there - as that is a group Id from >> > taverna-engine. >> > >> > (We have already changed the groupIDs to correspond to the repository >> > which corresponds to the release name, so at least that correspondance >> > is easy to check on Taverna, but not so on many other projects). >> > >> > >> > As binary releases from Apache Software Foundation are considered >> > "convenience only" they are not crucial for the vote - the source >> > release is the golden thing which everything else should be made from. >> > Practically speaking "everyone" uses the JARs from Maven repository >> > though, so I wouldn't dismiss them totally - at least one person in >> > the vote should do such a check. >> > >> > >> > > (4) How do I check the dependencies? >> > >> > mvn dependency:tree gives a nice list - but what should you check for? >> > Well, it's mainly about licensing - >> > http://www.apache.org/legal/resolved.html lists what is compatible as >> > dependencies of an ASF release. Now you don't need to go through the >> > list - but sometimes there are Well Known forbidden dependencies that >> > People (tm) recognize -e.g. mysql-connector and Hibernate are banned >> > as they are (L)GPL. >> > >> > Luckily there's another Maven plugin that can do the job: >> > >> > mvn license:aggregate-add-third-party >> > >> > cat target/generated-sources/license/THIRD-PARTY.txt | sort >> > >> > (Aduna BSD license) OpenRDF Sesame: HTTP client >> > (org.openrdf.sesame:sesame-http-client:2.7.0 - >> > http://www.openrdf.org/sesame-core/sesame-http/sesame-http-client/) >> > (Aduna BSD license) OpenRDF Sesame: HTTP protocol >> > (org.openrdf.sesame:sesame-http-protocol:2.7.0 - >> > http://www.openrdf.org/sesame-core/sesame-http/sesame-http-protocol/) >> > (..) >> > (The Apache Software License, Version 2.0) Xerces2-j >> > (xerces:xercesImpl:2.11.0 - https://xerces.apache.org/xerces2-j/) >> > (Unknown license) commons-beanutils >> > (commons-beanutils:commons-beanutils:1.7.0 - no url defined) >> > (Unknown license) com.springsource.org.jaxen >> > (org.jaxen:com.springsource.org.jaxen:1.1.1 - no url defined) >> > (Unknown license) com.springsource.org.jdom >> > (org.jdom:com.springsource.org.jdom:1.1.0 - no url defined) >> > (Unknown license) Logging (commons-logging:commons-logging:1.0.3 >> > - http://jakarta.apache.org/commons/logging/) >> > >> > (BTW, those last 4 are already checked to be OK, see >> > http://dev.mygrid.org.uk/wiki/display/developer/Third-party+licenses ) >> > >> > >> > > Regarding the build output: Since this is the first time I've done >> this, >> > I >> > > don't know what's okay to ignore. Here is a summary of the warning >> > messages >> > > I received when I ran mvn clean install. I sent the output to two >> > different >> > > files using the following command (Windows 10/ GitBash): mvn clean >> > install >> > >> output1.txt 2> output2.txt. I appreciate any insight. >> > >> > Great! I think those should be tracked in JIRA as we want to reduce >> > warnings. >> > >> > >> > >> > Generally with Maven, if it finishes with a big SUCCESS, then that's >> > true. The warnings are more like warnings for the developers doing >> > bad-practice-stuff than warnings about something going wrong with the >> > build. Often the fixes are simple, like adding a @Deprecated tag >> > where you delibately use old APIs, or actually follow the fix >> > suggested by the warning. >> > >> > I think we want to follow Andy's advice and "release early, release >> > often" - which entails a "good enough" - not "super-perfect". >> > Obviously each committer votes independenly by their own quality >> > measures. >> > >> > While Apache Software Foundation always says that community is king - >> > the Apache name is still recognized by the public as a kind of >> > "quality mark" - if that is deserved or not I won't comment on, but of >> > course there is also a sense of pride in that we don't want to set the >> > standard too low. :) >> > >> > (E.g. Taverna just cancelled 3 release candidates as they didn't pass >> > all their tests on Windows - but the community of another Apache >> > project might not consider Windows important enough to halt a release) >> > >> > >> > >> > >> > -- >> > Stian Soiland-Reyes >> > Apache Taverna (incubating), Apache Commons RDF (incubating) >> > http://orcid.org/0000-0001-9842-9718 >> > >> -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
