hi Phillip, I think you have it right. The basic idea is that the release artifacts being voted on must be placed in the SVN dist system with their checksums and signatures. The source release script already commits the artifacts and sigs/checksums to SVN [1]
Any released code artifact (source or binary) needs to have a checksum and signature so its authenticity can be verified [2]. You will need to commit your GPG public key to the KEYS file in SVN since this is your first time. You'll need someone in the network of trust to sign your key (e.g. I can sign your key since we are local in NYC). The package build system does not yet have the ability to upload to SVN. Probably want to write a script for this: https://github.com/apache/arrow/blob/master/dev/tasks/crossbow.py#L533. How has this download/sign process evolved since we now have a tag for each task, and some of the Linux package artifacts have the same name for the different distro targets. You are almost certainly going to run into problems starting from where things stand right now; I'll be available to help as needed - Wes [1]: https://github.com/apache/arrow/blob/master/dev/release/02-source.sh#L105 [2]: https://www.apache.org/dev/release-signing.html On Wed, Jul 25, 2018 at 3:04 PM, Phillip Cloud <cpcl...@gmail.com> wrote: > I'm think I'm still a bit confused about the order in which things need to > happen to cut a release candidate. > > My understanding is that the ordering is: > > 1. create the source release > 2. build packages from the source release (wheels, conda packages, etc) > 3. commit source release + binary packages and a signature for each (?) to > SVN > 4. kick off the release vote > > @wesm Can you provide some guidance here? I feel like I might be > misunderstanding or missing something here.
