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.
