incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [VOTE] Release 1.5.1 of NetBeans HTML/Java API
Date Sat, 18 Nov 2017 20:46:19 GMT
BTW, I've just noticed that the vote mail does not include a link to
the source tag.

So I don't know how anyone can have checked the contents of the source
archive against the code repo.

On 18 November 2017 at 20:41, sebb <sebbaz@gmail.com> wrote:
> On 18 November 2017 at 18:28, Jaroslav Tulach <jaroslav.tulach@gmail.com> wrote:
>> 2017-11-17 22:59 GMT+01:00 sebb <sebbaz@gmail.com>:
>>
>>> On 17 November 2017 at 21:13, Jaroslav Tulach <jaroslav.tulach@gmail.com>
>>> wrote:
>>> > 17. 11. 2017 v 12:48, sebb <sebbaz@gmail.com>:
>>> >
>>> >>> On 16 November 2017 at 22:19, Jaroslav Tulach <
>>> jaroslav.tulach@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message