Hi All, I have been traveling and slow in catching up with Airavata. Since the last release candidate and issues Ate raised, we have addressed them and made some developments. But I see a flood of new JIRA tasks as well. How about we freeze development for couple of days, test, address and close any open issues and prepare for 0.2 release as discussed below?
Any one wants to suggest a time line when we will be able to test and update documentation and get ready for the release? If there is enough active development and if release is not going smoothly, we can branch 0.2-snapshop and release the branch and ensure everything is sync'ed back. Suresh On Nov 17, 2011, at 5:03 AM, Ate Douma wrote: > On 11/16/2011 05:01 PM, Lahiru Gunathilake 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.. > > AFAIK the trunk now is on 0.2-incubating-SNAPSHOT. > As 0.1-incubating already has been tagged (and tags should never be > deleted/reused IMO), so we should be looking at creating a new 0.2-incubating > tag instead of a RC3. > > Not sure why you want to or think need to first branch to create a > 0.2-incubating tag. Typically this all can be done in one step from the trunk > using the maven-release-plugin. 'Downside' of that is that you typically > don't do 'RC' builds anymore, but once a build is stable/proper (from a > technical and construction POV) doing RC builds only adds up on the work in > my experience. > > Creating branches is more useful IMO for specific (refactoring) experiments > or (more importantly) maintenance trees, e.g. once Airavata 1.0(.0) is > released you might want to create a 1.0.x branch (or 1.x branch) as a > 'maintenance trunk' for development of minor update releases while trunk > development moves to 1.1 (or 2.0). > > If however you desire to use RC preparation branches (so trunk is free to > move forward, but then you'll need to 'sync' changes from the RC branch > back), that's fine too, but I then suggest using explicitly naming for such > branches. > The current RC branch was called 0.1-incubating, which IMO then better should > have been called 0.1-incubating-SNAPSHOT > > Ate > >> >> 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 >>>> >>> >>> >> >> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
