incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaroslav Tulach <jaroslav.tul...@gmail.com>
Subject Re: [VOTE] Release 1.5.1 of NetBeans HTML/Java API
Date Sun, 19 Nov 2017 16:52:55 GMT
18. 11. 2017 v 21:46, sebb <sebbaz@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 <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
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message