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
