The release email has been getting longer and longer because each release manager seems to want to add 'helpful' stuff. But we need to stay focused on the goal of the release vote: verify the integrity of the source distribution.
The extra stuff in the email can be a distraction from that task. I was not able to vote on the release on Saturday because there was no working link to release notes. And on Tuesday morning, as I write this, the vote has been closed already. So, please go back to what we used to do: a link to the release notes in the github tag, like this: https://github.com/apache/calcite/blob/calcite-1.24.0-rc0/site/_docs/history.md It's not good to rely on shared scripts. The release vote is the last chance for humans to find stuff that the automation has missed. If we're all using the same script, we'll all test the same things and miss the same things. To repeat, we should remove the build instructions from the email. Every reviewer should download the tarball, and follow the instructions in the tarball. Otherwise you're not verifying the release, you're verifying what you imagine to be the release. Julian On Tue, Oct 6, 2020 at 7:45 AM Stamatis Zampetakis <[email protected]> wrote: > > I'm fine with the content of the email but obviously we should not put > inside things that do not work. > If we don't have a site preview then it is confusing to have a broken link > in the vote email and the same goes for the rest. > > Best, > Stamatis > > On Sat, Oct 3, 2020 at 9:11 PM Vladimir Sitnikov < > [email protected]> wrote: > > > Julian>Also, please don't double-space the email; if you get extra > > linefeeds > > when you copy-paste, remove them manually > > > > +100500 > > > > Julian>The release notes > > Julian>should be at a URL whose contents will not change after the vote > > (not > > Julian>in the site preview) > > > > Where does that requirement come from? > > Release notes are volatile, and they are subject to further refinement. > > For instance, if we identify a regression, then we could update old notes > > to mention the regression. > > > > --- > > > > Just in case, here's a sample vote mail for Apache JMeter (all the links > > are working there): > > > > https://lists.apache.org/thread.html/228e422bd97f55717d06406664d6727b6e1294d2b906b8eff8453cea%40%3Cdev.jmeter.apache.org%3E > > > > > > Julian>much of the other site preview stuff > > > > Site preview is non-trivial to generate (it might require Docker or > > whatever). > > > > On top of that, if JavaDoc was shared in a clickable way, then we could > > review > > the documentation for the newly added features. > > > > Julian>the release should be self-contained and self-explanatory, right? > > > > I'm afraid if we remove all the links and instructions, the number of the > > number of > > votes would drop dramatically. The quality would drop as well, as people > > would > > skip things. > > > > > > I would clarify: even though we use Gradle for a while, > > people might be not familiar with the command to prepare release artifacts. > > On top of that, they might be shy admitting they have no idea how to build > > artifacts and where to find them. > > > > That is why I added the exact command to reproduce the release artifact > > in the initial draft of the vote mail (./gradlew build -Prelease > > -PskipSign). > > That command enables us to reproduce the artifact byte-by-byte. > > For some reason, someone suggested removing options from the command, > > and it was strange to me as "gradlew build" produces a slightly different > > archive. > > > > Even though I know all the commands and locations, I would love to add > > the sequence of shell scripts to validate the artifacts. > > > > Here's the script I use to validate Apache JMeter releases: > > > > https://lists.apache.org/thread.html/9127d0d5036c845ab882e0f2d0d7df7faf3e20855c07fc4b1c5c50ab%40%3Cdev.jmeter.apache.org%3E > > > > In my point of view, a sequence of commands to validate the release > > would definitely help, and we would get more votes. > > > > Julian>We definitely don't need the RAT report > > > > I'm -0 on that. ASF policy says that the licensing is of utter importance, > > so RAT report is important. > > On the other hand, RAT violations would fail the build, so the report is > > not very useful. > > However, it does highlight binary files (which we don't expect to have a > > lot). > > > > Frankly speaking, I can easily review RAT report if it is provided via > > link, however, > > it is likely I won't generate one on my own. > > > > For those who are curious, you might check JMeter's report: > > https://jmeter-preview.apache.org/rat/ > > > > Vladimir > >
