Thanks for pointing out. I can do a manual retag and push. Olaf Flebbe <[email protected]>於 2017年4月6日 週四，下午12:25寫道：
> 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. > > >> > >
