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 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). -jt
