I am +1 to create RC3 with trunk but we should branch again first and then do the RC3. I have few more commits to go.. Suresh can you please wait until you branch from trunk..
Lahiru On Wed, Nov 16, 2011 at 10:35 AM, Suresh Marru <[email protected]>wrote: > 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 > > > > -- System Analyst Programmer PTI Lab Indiana University
