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 >
