please do not regenerate the images! it will trigger the 1.8.0_121 bug related to javascript in javadocs. retag it.
had no time to do it in time. > Am 04.04.2017 um 21:03 schrieb Evans Ye <[email protected]>: > > +1. > > Signatures looks good. > Tested docker and vagrant provisioners. > Though discovered many deployment(puppet) issues, we can fix it later. > > Echo Olaf's suggestion, we should push 1.2 toolchain images. > I can help to do that using our Jenkins: > > https://ci.bigtop.apache.org/view/Docker/job/Docker-Toolchain-1.2.0/ > > > > 2017-04-04 8:41 GMT+08:00 Roman Shaposhnik <[email protected]>: > >> Hi Ed! >> >>> On Mon, Apr 3, 2017 at 1:09 PM, Ed Espino <[email protected]> wrote: >>> I'm on the Apache HAWQ Incubator project. Our initial binary release will >>> be validated against TLP Apache Bigtop. Coincidentally, our release paths >>> are crossing as both projects are currently in the early stages of their >>> respective voting processes. I have a few of very preliminary >>> "Observations" to share as I am getting acquainted with Bigtop. I'm also >>> fairly new to the Apache release processes and my comments might be >>> slightly off point (so please bear with me). >> >> First of all -- welcome to the Bigtop community and thanks for taking time >> to share your feedback. See my comments inline below: >> >>> LICENSE: I noticed the LICENSE file only contains the ASF v2.0 >>> license. Is there a need to mention the licenses of the >>> tools recommended for rapid provisioning (example; Vagrant, >>> Docker, Puppet) or other non-ASF projects? >> >> Strictly speaking: no. Sine these tools are not being touched in any way >> by the Bigtop codebase. This is similar to how we don't mention the >> license of make when we ship makefiles. >> >>> NOTICE: Copyright year needs to be updated (currently 2014) >>> >>> Should it change to a range (2014-2017)? >> >> Great catch! I filed https://issues.apache.org/jira/browse/BIGTOP-2731 >> >>> OBSERVATION: The format of the hashes is not super convenient for an >>> automatic comparison. Being compatible with command >>> line tools would be helpful. >> >> Good point, but our checksums are generated automatically by doing >> a Maven release to the ASF Maven repo. That determines the format. >> Once we complete our transition to Gradle in 1.3.0 -- I'll try to see if >> we can make the format more friendly. >> >>> ====================================================================== >>> GIT TAG >>> ====================================================================== >>> >>> Git tag matches src (except .git*) >>> commit: 5a2a1a86b17f73260229137b0b008385fd32bfae >>> >>> OBSERVATION: I noticed the commit hash was not provided. I've seen >>> several podling votes with them. Should the hash also >>> been provided along with the corresponding tag? >> >> Given that tags under rel/ are supposed to be immutable I don't see a >> strong >> reason for why hash would be required. This wasn't the case a year or so >> ago and that's probably why you see hashes still being given. >> >>> ====================================================================== >>> Apache RAT >>> ====================================================================== >>> >>> The "gradlew rat" execution passed. >>> >>> OBSERVATIONS: >>> >>> * Initially I ran using maven and have come to know I should use >>> gradle. For grins, I generated a RAT Report summary using maven >>> which intentionally did not have any exclusions identified. >>> >>> Here is the "mvn apache-rat:check" summary which generated >>> a few followup observations (below): >>> >>> ***************************************************** >>> Summary >>> ------- >>> Generated at: 2017-04-03T11:59:14-07:00 >>> >>> Notes: 97 >>> Binaries: 9 >>> Archives: 3 >>> Standards: 1994 >>> >>> Apache Licensed: 1353 >>> Generated Documents: 0 >>> >>> JavaDocs are generated, thus a license header is optional. >>> Generated files do not require license headers. >>> >>> 641 Unknown Licenses >>> >>> ***************************************************** >>> >>> * Should the yaml files included in the release have ASF headers? It >>> is possible the parsers have troubles with comment ASF headers. But >>> then again, maybe the current parsers can handle them. >> >> Another great find. I believe originally we had problems with Puppet and >> Juju >> YAML parser somehow choking on comments. I'm pretty sure that is no longer >> the case -- but we need to make sure. I filed >> https://issues.apache.org/jira/browse/BIGTOP-2732 >> to address this. >> >>> * There are three archives. Are these acceptable? >>> >>> + >>> bigtop-packages/src/charm/giraph/layer-giraph/resources/ >> giraph-examples-1.1.0.jar >>> + bigtop-tests/test-artifacts/hadoop/src/main/resources/cachedir.jar >>> + >>> bigtop-tests/test-artifacts/hadoop/src/main/resources/test_data/test.zip >> >> I don't think these represent a problem, but you're right it would be >> much nicer not >> to have them on the exclusion list. We'll try to look into that as >> part of BIGTOP-2732. >> I think the ones in test are OK either way -- but the one in charms >> can be fixed. >> >> Thanks, >> Roman. >>
