18. 11. 2017 v 21:46, sebb <seb...@gmail.com>: > BTW, I've just noticed that the vote mail does not include a link to > the source tag.
True, I've added the tag yesterday when the vote was approved: https://github.com/apache/incubator-netbeans-html4j/tree/release-1.5.1 > So I don't know how anyone can have checked the contents of the source > archive against the code repo. One would have to check against the revision used by the Jenkins builder job run that I referenced in my email: https://builds.apache.org/view/Incubator%20Projects/job/incubator-netbeans-html4j-release/20/ -jt > >> On 18 November 2017 at 20:41, sebb <seb...@gmail.com> wrote: >>> On 18 November 2017 at 18:28, Jaroslav Tulach <jaroslav.tul...@gmail.com> >>> wrote: >>> 2017-11-17 22:59 GMT+01:00 sebb <seb...@gmail.com>: >>> >>>> On 17 November 2017 at 21:13, Jaroslav Tulach <jaroslav.tul...@gmail.com> >>>> wrote: >>>>> 17. 11. 2017 v 12:48, sebb <seb...@gmail.com>: >>>>> >>>>>>> On 16 November 2017 at 22:19, Jaroslav Tulach < >>>> jaroslav.tul...@gmail.com> wrote: >>>>>>> 72h is gone and (I think) we still need one more vote. C'mon it's a >>>> formality (version 1.5.1 is better than 1.5 and 1.5 was approved). Somebody >>>> please help us move on. >>>>>> >>>>>> Sorry to interrupt, but release approval is never a formality. >>>>> >>>>> As expected... I knew my comment would provoke a reaction. Too bad it >>>> didn't provoke a binding vote... >>>>> >>>>>> Each release must be separately approved. >>>>>> Things can go wrong when assembling the release artifacts. >>>>>> For example files can be omitted or spurious files can be included >>>>>> (did the RM use a clean workspace?) >>>>> >>>>> The release is prepared by a Jenkins job >>>>> https://builds.apache.org/view/Incubator%20Projects/job/ >>>> incubator-netbeans-html4j-release/ >>>>> The reason is simple - I don't trust myself to not make some stupid >>>> mistake and thus I automate as much as I can. Thanks to that I can remain >>>> convinced release 1.5.1 is better than previous version 1.5 and none of >>>> them contain any spurious files. >>>> >>>> Whilst automation helps to reduce errors, it cannot guarantee to eliminate >>>> them. >>>> >>> >>> Right. That is the reason why there are the human reviews. >>> >>> >>>> Can you prove that there are no bugs in the release script? >>>> Or any of the libraries that it depends on? >>>> >>> >>> I am not trying to, but: Can you tell me what is the probability that 3rd >>> human reviewer will find an error when: >>> >>> - the script is the same as in previous version >>> - the previous version was found OK by all human reviewers and approved >>> - the new version has already been successfully reviewed by two reviewers >> >> That was basically the scenario I mentioned in my previous comment. >> >>> I put my bet on the probability being extremely low and called the >>> remaining review a formality. Looks like I was the lucky winner (this time). >> >> My point is that the reviews are vital, and should not be dismissed as >> a mere formality. >> That route leads to complacency and potential errors (which is what >> happened in the example I mentioned). >> >>> -jt > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org >
