On 19 November 2017 at 16:52, Jaroslav Tulach <jaroslav.tul...@gmail.com> wrote: > 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 >
IMO the tag should be created first, and the RC created from it. >> 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/ Apart from having to rummage through the log to find the revision, AIUI Jenkins log files are not kept forever, so this information is not preserved for posterity. IMO for traceability it's vital that the vote email contains all the info that would be needed to re-run the checks at a later date if necessary. > -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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
