Hello Jernej,
[X] +1 Release this as Apache Burr 0.43.0 (binding)
[ ] +0
[ ] -1 Do not release this package because... (reason required)
Checklist:
[X] Download links are valid
[X] Checksums and signatures are valid
[X] LICENSE/NOTICE/DISCLAIMER files exist and are correct
[X] No unexpected binary files in source
[X] All source files have ASF headers
[X] Can build and test from source
I gave a binding -1 on RC0 over the wheel's LICENSE not accounting for the
npm packages bundled into the compiled tracking UI. RC1 fixes that properly,
so I am +1 here.
On the LICENSE fix specifically, since it was the blocker:
- LICENSE-wheel now carries a generated "THIRD-PARTY COMPONENTS BUNDLED IN
THIS BINARY DISTRIBUTION" section listing 130 npm packages with their
licenses and copyright lines. Licenses are Apache-2.0, BSD-3-Clause, ISC,
MIT and PSF -- no Category X.
- It is generated, not hand-maintained: scripts/generate_wheel_license.py
derives the list from a `vite build --sourcemap` run, resolving each
node_modules source back to its owning package. That is the right way to
do this, and it is the part that makes me confident it will not silently
drift on the next dependency bump.
- `generate_wheel_license.py --check` runs in CI
(.github/workflows/release-validation.yml), so a stale list fails the
build rather than costing another RC.
- All 130 listed entries match telemetry/ui/package-lock.json versions
exactly, and none of them is a dev-only dependency.
- I spot-checked the packages that look like they *should* be in the list
but are not -- micromark-util-symbol, highlight.js/lowlight, prismjs,
@floating-ui/core, reactflow, react-router-dom, character-entities -- by
grepping the shipped minified bundle for their distinctive string
literals. Each absence is legitimate: micromark ships constant-folded
builds so its symbol package contributes no code, the UI imports
{ Prism as SyntaxHighlighter } so the highlight.js path is tree-shaken
out, and the rest are type-only or re-export-only. The list is accurate,
not merely plausible.
The rest of my verification:
- All three SHA-512 checksums verify, and all three detached signatures are
good against the KEYS file at
https://downloads.apache.org/incubator/burr/KEYS, signed by Jernej Frank,
3959 450E 4AA8 9991 1547 112F 25CA 7FC3 4D7C 68C1.
- The signed tag v0.43.0-incubating-RC1 (object 30f4a9aa, commit 971a3530)
matches the tag on GitHub. The source tarball is byte-identical to that
tag: 820 files, every SHA-256 equal.
- No compiled objects, archives or built UI assets in the source artifact.
The single symlink (burr/examples -> ../examples) is present in git too.
- scripts/check_asf_headers.py reports clean.
- `twine check` passes on the wheel and the sdist, and the project's own
verify_apache_artifacts.py signatures/artifacts checks pass on all three
artifacts.
- Python test suite from the source tarball on 3.12: 665 passed, 5 skipped.
The two Ray tests did not run in my sandbox (Ray wants /tmp/ray and unix
sockets); that is my environment, not the release.
- The released wheel installs cleanly, reports 0.43.0, and the core,
tracking and server modules import with the relevant extras.
Two cosmetic follow-ups for a later release, on top of the ones Stefan
already raised in #882:
- scripts/README.md's policy table says tests ship in the sdist, but the
sdist has no tests/ directory. They are in the voting src.tar.gz, so the
artifacts are fine -- it is the doc that is out of step.
- verify_apache_artifacts.py's `signatures` command reports FAIL for every
non-artifact file that happens to sit in the directory it scans (it
flagged the KEYS file I had downloaded alongside the artifacts as
"missing .asc"). Worth filtering to the expected artifact names so voters
do not see spurious failures.
Thanks for turning RC0 around quickly.
Jarek
