+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. >
