Hi Chris, Thanks for pinging on and offering to help. We have enough features in 0.2 branch and 0.3 trunk for going for a quick two releases. I will email tonight with the list of tasks needed wrap to wrap release.
Thanks, Suresh On Jan 23, 2012, at 3:55 PM, Mattmann, Chris A (388J) wrote: > Hey Guys, > > What's the status of Airavata 0.2-incubating? Can I help? Do you need mentor > VOTEs or help respinning? Let me know and I'll try and find some time this > week > to take a look. > > Thanks! > > Cheers, > Chris > > On Dec 16, 2011, at 9:44 AM, Suresh Marru wrote: > >> Hi Chathura, >> >> I volunteer to take care of the incubator compliance. We have good attention >> to detail mentors, so if we address all the issues raised in community vote, >> we should be in good shape in general voting. Your time line sounds good. I >> do not think we want to branch before Friday (as per your testing time). We >> can defer the branching decision for now and probably focus on getting good >> testing done within this timeline. >> >> Suresh >> >> On Dec 16, 2011, at 12:22 PM, Chathura Herath wrote: >> >>> Hi Suresh, >>> >>> I went through the JIRA's and categorized to 0.2 and future release. >>> (This will yeild our 0.3 goals hopefully). From the looks of it i want >>> to focus on addressing few JIRA that i feel will be critical. I am >>> guessing we will be able to finish them by end of the day Monday next >>> week. >>> >>> Rest of the week for testing and we could make the release on next >>> Friday. I am hoping you will go through the trouble of generating the >>> distributions and incubator compliance. >>> >>> As for the branching, I would prefer to work on the trunk till Monday >>> if no other major development task that conflicts. >>> >>> Thanks >>> Chathura >>> >>> On Fri, Dec 16, 2011 at 11:52 AM, Suresh Marru <[email protected]> wrote: >>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -----BEGIN PGP SIGNATURE----- >>>> >>>> iQIcBAEBAgAGBQJO63c3AAoJEHmz9P1hfdutxzkP/jNDPTeqX786+ySaBVMIrHn7 >>>> 7KgJ2ED31H3CBLBcTHHSFe6ohg/cCmRH612OiovIHcLRGgebD3P+a+kYiNIE9WQt >>>> QT/wEx8MYZP8B4gHswqtnUwK/PAf3Z45I4W3Sthrh4zhj99Sl2S5jJGDVvXsp+L2 >>>> DvtSlrXyHC5QjvihzzWe1tFZqcDBRmSMhwITcot224xbUH7Sjt+TNiEYdSPj0EBK >>>> psg7lISLJt0CT5G+gax8RaJqnv2oIH97KF2AJAr3mnEBC1Z0yJnGPlIo/LoO0z6i >>>> OEZry4KKHA/oDlZpatdiJtxTPu2gXd2NldP7/PZgV6kdtP6pTXT3vB5/IEL8n/O4 >>>> u7u1kJJyMYZh8m9WpdaRd92S78M6NTqJs8i9gCSiHgh2+mT5U94HedgeXBySpv8A >>>> l6u3lQjG84r3ILuG49VfycMj2hb8aO/FCjJOtuQgKlgz8e/xb3s2Df69b+GsAVNr >>>> CAPG9b5d2KlCmkxQ+js5igWbtHLFKmL+eVWzl96MBGx/YM7O+szkzNp8892tXf8V >>>> a6MN8p4BdL4Z286HY+iJGHRvgTRPN6H8hnJnEAAS8siO1c3itEbfSvV2DWEq5Pgr >>>> uis5HUP9k4m2kGHOfqy1G+7aWgnVl4mG7s2nOsE/0KhFxZdxt4GgzoIJadz5UoRN >>>> lAjoS84lmDUSRjG3QI54 >>>> =mawE >>>> -----END PGP SIGNATURE----- >>>> >>> >>> >>> >>> -- >>> Chathura Herath >>> http://people.apache.org/~chathura/ >>> http://chathurah.blogspot.com/ >> > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: [email protected] > WWW: http://sunset.usc.edu/~mattmann/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Adjunct Assistant Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >
signature.asc
Description: Message signed with OpenPGP using GPGMail
