incubator-airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject Re: [DISCUSS] Apache Airavata 0.2-Incubating Release Candidate
Date Tue, 31 Jan 2012 17:01:37 GMT
I've found a (too) short period of time to do a quick review of the release 
candidate, looking only at the L&N&D requirements so far.

Regrettably, I can only conclude that this release candidate isn't complaint 
with the requirements and I'll have to vote -1 on it.

I also (just now) noticed, while looking back on the discussion thread we had on 
the 0.1-incubating (RC 2) release vote, that Chathura pinged me (during the 
Christmas holidays) with questions about my earlier comments.
I'm sorry I missed that one, otherwise maybe I could have given some earlier 
feedback on these still outstanding problems.
Please don't hesitate to ping me again or even directly if I'm not responding: 
typically I get 100ths of emails a day and certainly after a holiday I tend to 
have missed one or two :)

The major problem I noticed, and actually something I reported also on the 
previous release candidate, is that several or even all 'aggregating' artifacts, 
including the release binary but also for example 
gfac-axis2-interface-0.2-incubating.jar, messagebox-0.2-incubating.jar, 
messagebroker-0.2-incubating.jar, etc. contain many embedded 3rd party 
dependencies which should have been covered in each of these artifacts their own 
NOTICE and/or LICENSE file.

As a very trivial example, take any of these jar (not the bin) artifacts and all 
of them embed slf4j, but none of them have the required license for slf4j 
appended to their LICENSE file (actually: no other license is appended).
And there are *many* 3rd party dependencies embedded in these examples, and 
there are probably more (I haven't checked each and everyone).
IMO these omissions qualify as a blocker for a release.
Each released artifact should be regarded as 'standalone' and comply to the full 
N&L requirements for everything they contain.

And this should even include and cover embedded 3rd party artifacts *own* 
(embedded) N&L.

For example, the release binary artifact (tar.gz or zip) bundles the 
jackrabbit-standalone-2.2.7.jar. This of course is a release from an Apache 
'sister' project, meaning there is not need to provide a notice for jackrabbit 
However, this particular artifact *itself* bundles many 3rd party dependencies 
(merged within the jar file), and if you check the embedded NOTICE and LICENSE 
file you'll see they (properly) cover many 3rd party licenses and notices. By 
bundling this jackrabbit-standalone artifact, Airavata is required to merge 
those into its own (root) NOTICE and LICENSE files as well.

I can understand this can be quite frustrating, and belief me I've just went 
through several hours of (re)checking and updating/fixing similar problems for 
only *one* module (rave-shindig) within Apache Rave myself. However, once these 
issues are recognized (and they were pointed out before), they cannot be ignored 
anymore. Ignorance is bliss as they say, but we're past that point now.

So my suggestion is to retract the VOTE and create dedicated JIRA issues for 
tracking, fixing and then *validating* these issues *before* calling a next 
vote. I'm surely willing to help validating the results, but my time is too 
limited right now to help doing the grunt work.

As a quick heads-up how to deal with these requirements properly, may I suggest 
reading the mail I send last week to dev@shindig about the similar thing there:

On 01/29/2012 09:47 AM, Suresh Marru wrote:
> Discussion thread for vote on airavata 0.2-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 -
> Incubator specific release guidelines -
> 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

View raw message