On Mon, Apr 14, 2025 at 2:42 AM Piotr Gankiewicz <pi...@apache.org> wrote: > > On 2025/04/14 06:29:23 Yonik Seeley wrote: > > On Mon, Apr 14, 2025 at 2:20 AM Piotr Gankiewicz <pi...@apache.org> wrote: > > [...] > > > Could be, that when building the artifact, some of the files from running > > > the integration tests weren't cleaned up properly (all this temp > > > local_data directories). As for the Apple specific files, we'll make sure > > > to build artifact always on Linux, to avoid any confusion. And we'll also > > > move all the files into the root directory, as suggested. > > > > Is there a way instead to take the proposed release artifact, extract > > it, and then run all the tests? > > That's a more robust way to make sure that everything needed is > > included in the artifact. > > > > > > > > > Regarding licenses: I see these files: > > > > ./licenses > > > > ./licenses/ring-BoringSSL.txt > > > > ./licenses/passterm-BSD 3-Clause.txt > > > > > > > > Is there source code using these licenses included in the > > > > distribution? If so, I think the top-level LICENSE file may need to > > > > reflect that. > > > > https://infra.apache.org/licensing-howto.html > > > > > > As you can see in the dependencies.md file, there are just a few > > > libraries that we use (from crates.io), which do not have Apache 2.0 / > > > MIT (or similar) license, thus we explicitly added these licenses to this > > > directory. We do not publish the source code of these libraries as part > > > of the artifact (these are just used to build the project as the external > > > dependency). > > > > OK, it's fine then. It's only directly included bits that need to be > > reflected in the LICENSE/NOTICE. > > > > -Yonik > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > The release artifact can be compiled and then tested directly in its current > form, the mentioned temp files (from the past integration tests) are not > needed for this at all. As described in the initial voting thread, you could > just run `cargo build` and then `cargo test` (given that the Rust is > installed), and it will compile + test out of the box. It's the same, as if > you were to clone our repository, nothing else is needed.
Sorry, I was a bit unclear. I think the release artifact itself should ideally be created from a git tag for the release, and at most a version string changed. Using an actual working/development checkout is error prone. So I'd suggest first creating a tag, then using something like "git archive" to get a fresh copy of just the tagged files, then run the release creation script on that. It looks like we're releasing off of the main branch (and eyeballing what the version numbers should be), which is fine for a start, but for a server my recommendation would be to eventually migrate to branches for every MAJOR.MINOR release and tags for the patch-level releases on those branches. > What would you propose to do as the next step? Should we prepare another > release artifact (without this temp files under integration tests) and then > start the initial voting once again? I don't see a legal reason for a respin. If this was out of the incubator and had a lot of ASF users of the actual source archive, then I would just for aesthetics of a professional looking release. But I don't think that's how most people will be getting started. -Yonik --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
