Hi All, I suggest we make the RC3 with latest from trunk which includes some of the improvements/big fixes made after RC2. Any objections? If I do not see any objections, I will add the new JIRA's to the release notes and after we address rest of missing notice/license, re-tag from trunk itself.
Suresh On Nov 16, 2011, at 6:35 AM, Suresh Marru wrote: > Hi Ate, > > Thank you very much for the detailed feedback, will go by them one by one to > address them. > > Suresh > On Nov 16, 2011, at 5:48 AM, Ate Douma wrote: > >> I've shortly reviewed this release candidate and found several issues with >> it which regrettably makes me have to vote -1 on this candidate: >> >> - BLOCKER: none of the *.jar artifacts (including derived build >> -javadoc.jar, -sources.jar) contain the required incubator DISCLAIMER file >> >> - BLOCKER: the binary distributions LICENSE/NOTICE files are not covering >> all bundled external dependencies which have/require separate mentioning, >> e.g. like activation-1.1.jar (CDDL license!), jaxen-1.1.1.jar, >> logback-*.jar, jibx-*.jar, mex-*.jar, and probably (much) more, I stopped >> checking after finding already these. >> In general any bundled artifact should be checked proper what license/notice >> requirements it needs. For some this can be derived from the jar itself but >> many don't have any so they need looking up elsewhere. And even for ASF >> provided artifacts this is needed as some have *additional* notices (beyond >> the default ASF notice) which then also should be covered/copied in the >> project NOTICE file. I also see several edu.indiana provided artifacts >> (weps-beans, pegasuswebservice, maybe more) of which it isn't clear to me >> if/what license requirements they have. I see xpp3 mentioned in the NOTICE >> file, but not these? >> >> - In addition I see several cryptix-* and jce-* libraries bundled: I suppose >> these contain encryption techology/algorithms. I'm not sure if/how these >> should be handled and/or require special notices. Possibly not, but I >> suggest asking this specifically on general@incubator or check related >> documents just to be sure (this is not my expertise). >> >> - The binary distributions contain a lot license files under >> standalone-server/lib which are not needed, at least not from ASF pov (the >> root LICENSE/NOTICE files already should cover everything), besides there >> are even some for artifacts which aren't even bundled... >> >> - The -source.tar.gz and -source.zip distributions, which are different from >> the already automatically maven produced >> airavata-0.1-incubating-source-release.zip, have .svn folders embedded. It >> wonder why these separate source distributions are made anyway as maven >> already produces the only one needed... >> (note: if only using this -source-release.zip, it is required to copy this >> to the official download area on the apache server) >> >> - POSSIBLE BLOCKER: The binary distributions (both .tar.gz and .zip) are >> also 'build' through maven *and* deployed to the repository. However these >> have different sizes. I haven't actually (binary) compared them but this >> seems odd. Furthermore, I would suggest not to deploy these binary >> distributions to the repository as they have no usage from a maven (build) >> perspective and these distributions in any case are required (at least) to >> be downloaded through the main apache server(s), something which maven >> central is *not*. Redundantly providing these also through the maven >> repository seems unneeded, if not undesired. >> >> - The distribution module also uses packaging type 'jar' (default). For >> assembly only poms better use packaging type 'pom', because now even a >> 'distribution-0.1-incubating.jar' (and derived -sources.jar) is >> produced/deployed, which is useless. >> To prevent deploying the assembly produced binary artifacts to the remote >> repositories just add <attach>false</attach> to the assembly plugin config. >> >> Ate >> >> On 11/11/2011 06:35 PM, Suresh Marru wrote: >>> Discussion thread for vote on airavata 0.1-incubating release candidate 2. >>> >>> If you have any questions or feedback or to post results of validating the >>> release, please reply to this thread. >>> >>> For reference, the Apache release guide - >>> http://www.apache.org/dev/release.html >>> Incubator specific release guidelines - >>> http://incubator.apache.org/guides/releasemanagement.html >>> >>> Some tips to validate the release before you vote: >>> >>> * Download the binary version and run the 5 minute or 10 minute tutorial as >>> described in README and website. >>> * Download the source files from compressed files and release tag and build >>> (which includes tests). >>> * Verify the distributon for the required LICENSE, NOTICE and DISCLAIMER >>> files >>> * Verify if all the staged files are signed and the signature is verifiable. >>> * Verify if the signing key in the project's KEYS file is hosted on a >>> public server >>> >>> Thanks for your time in validating the release and voting, >>> Suresh >
