Re: [DISCUSS] Apache Airavata 0.1-Incubating RC 2

[Ate Douma]

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<sma...@cs.indiana.edu>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