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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
