Hi Suresh, I am done with changes.. now when you build source pack is created and I did some XBaya changes too.
Lahiru On Wed, Nov 16, 2011 at 11:01 AM, Lahiru Gunathilake <[email protected]>wrote: > 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 > > -- System Analyst Programmer PTI Lab Indiana University
