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 > > > > > >
