I tend to just follow the discussions here, but I was also curious. I think it works by combining: https://github.com/apache/calcite/blob/master/release/build.gradle.kts <https://github.com/apache/calcite/blob/master/release/build.gradle.kts> With https://github.com/vlsi/vlsi-release-plugins/tree/master/plugins/stage-vote-release-plugin <https://github.com/vlsi/vlsi-release-plugins/tree/master/plugins/stage-vote-release-plugin>
- jfs > On Oct 6, 2020, at 11:46 AM, Julian Hyde <[email protected]> wrote: > > Where does the script live that generates the vote email? I don't > think it's even in our code base. > > Julian > > On Tue, Oct 6, 2020 at 11:33 AM Ruben Q L <[email protected]> wrote: >> >> Hi all, >> >> First of all, I apologize, this was my mistake, as I should have double >> checked the content (and the links) of the email. >> FYI, I have created https://issues.apache.org/jira/browse/CALCITE-4312 to >> track this issue. >> >> Best, >> Ruben >> >> >> On Tue, Oct 6, 2020 at 7:15 PM Julian Hyde <[email protected]> wrote: >> >>> 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 >>>>> >>>
