Hi, Thanks for taking time, but i have few suggestion of my own.
When i try to manage the release last holidays, i went by the release guideline document[1]. Is this the recommended document is there any other reference. If that is the document there is room for improvement. I am not passing any buck here, i am willing to improve/add if to comes to that. This way we have document shall get refined and improvement in the release management process and reduce this back and fourth over the same issue because of misunderstandings. My point is as much as Ate's mail thread link and JIRA's it refer to, are extremely useful; it is not a sustainable model of all the project. So the vote down that is not due to mistake/ignorance on the part of the incubator dev shall have positive outcome across projects. Finally I think i now understand what is meant by "all attribution and copyright notices required by licenses for third party documents" least what it is suppose to mean. Thanks Chathura [1] http://incubator.apache.org/guides/releasemanagement.html On Tue, Jan 31, 2012 at 12:01 PM, Ate Douma <[email protected]> wrote: > 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 itself. > 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: > > > http://mail-archives.apache.org/mod_mbox/shindig-dev/201201.mbox/%[email protected]%3E > > > 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 - >> 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 > > -- Chathura Herath Ph.D http://people.apache.org/~chathura/ http://chathurah.blogspot.com/
