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).
Regards,
-=e
## ======================================================================
## Apache Bigtop
## 1.2.0-RC1
## ======================================================================
file(s):
bigtop-1.2.0-project.tar.gz
bigtop-1.2.0-project.tar.gz.asc
bigtop-1.2.0-project.tar.gz.asc.md5
bigtop-1.2.0-project.tar.gz.asc.sha1
bigtop-1.2.0-project.tar.gz.md5
bigtop-1.2.0-project.tar.gz.sha1
======================================================================
Spot checked LICENSE/NOTICE files
======================================================================
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?
NOTICE: Copyright year needs to be updated (currently 2014)
Should it change to a range (2014-2017)?
======================================================================
PGP Signature
======================================================================
Signature is good:
Verification:
gpg2 --verify bigtop-1.2.0-project.tar.gz.asc
gpg: assuming signed data in 'bigtop-1.2.0-project.tar.gz'
gpg: Signature made Wed Mar 29 18:37:48 2017 PDT
gpg: using DSA key 13971DA39475BD5D
gpg: Good signature from "Roman V Shaposhnik (CODE SIGNING KEY) <
[email protected]>" [unknown]
gpg: aka "Roman V Shaposhnik <[email protected]>" [unknown]
gpg: aka "Roman V Shaposhnik <[email protected]>"
[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
======================================================================
Checksums
======================================================================
md5 and sha1 are good (for both bigtop-1.2.0-project.tar.gz and
bigtop-1.2.0-project.tar.gz.asc)
Verification:
10:21 $ gsha1sum bigtop-1.2.0-project.tar.gz
f01813b17816f031d4e9dab7cc8871d6231cc610 bigtop-1.2.0-project.tar.gz
10:21 $ cat bigtop-1.2.0-project.tar.gz.sha1
f01813b17816f031d4e9dab7cc8871d6231cc610
10:21 $ gmd5sum bigtop-1.2.0-project.tar.gz
cfbf3f9efb0aef1b1f91f5bf588e8d46 bigtop-1.2.0-project.tar.gz
10:22 $ cat bigtop-1.2.0-project.tar.gz.md5
cfbf3f9efb0aef1b1f91f5bf588e8d46
10:22 $ gmd5sum bigtop-1.2.0-project.tar.gz.asc
db3ceee21aea5d6d527e561ec0bcef75 bigtop-1.2.0-project.tar.gz.asc
10:22 $ cat bigtop-1.2.0-project.tar.gz.asc.md5
db3ceee21aea5d6d527e561ec0bcef75
10:22 $ gsha1sum bigtop-1.2.0-project.tar.gz.asc
b0716f7a7c66b81fe64943fdc1113441b855de58 bigtop-1.2.0-project.tar.gz.asc
10:22 $ cat bigtop-1.2.0-project.tar.gz.asc.sha1
b0716f7a7c66b81fe64943fdc1113441b855de58
OBSERVATION: The format of the hashes is not super convenient for an
automatic comparison. Being compatible with command
line tools would be helpful.
example:
$ gsha1sum bigtop-1.2.0-project.tar.gz >
bigtop-1.2.0-project.tar.gz.sha1
$ gsha1sum --check bigtop-1.2.0-project.tar.gz.sha1
bigtop-1.2.0-project.tar.gz: OK
======================================================================
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?
======================================================================
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.
* 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
On Fri, Mar 31, 2017 at 10:39 PM, Konstantin Boudnik <[email protected]> wrote:
> One way of doing this is to make Weather Report of our standard CI
> process. Anyway...
>
> +1 on the release
> --
> Take care,
> Konstantin (Cos) Boudnik
> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
>
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
>
>
> On Fri, Mar 31, 2017 at 10:11 PM, Roman Shaposhnik <[email protected]>
> wrote:
> > On Fri, Mar 31, 2017 at 8:49 PM, Konstantin Boudnik <[email protected]>
> wrote:
> >> I have deployed a trivial cluster and ran some MapReduce example and
> >> everything worked!
> >>
> >> The bad news: I found some bugs in the Ignite's deployment (or rather
> >> the discrepancies in 1.9's expectations for the configuration files).
> >> It isn't perhaps a blocker, but I would like to spend a bit of time
> >> (hopefully over the weekend) to fix it.
> >>
> >> I would be ok if we don't consider this as a blocker though.
> >
> > I'd advocate for the same here. In fact, I'd say -- lets focus on
> > core functionality working in 1.2 and once it is out focus on CI
> > to make sure things like Puppet stay functional.
> >
> > Thanks,
> > Roman.
>
