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