On 10 December 2016 at 10:54, Stian Soiland-Reyes <st...@apache.org> wrote:
> That sounds like not a problem at all as RAT passes on the RC.
> Just regenerate the site after releasing. (We have to verify download page
> manually anyway).
>
> (Perhaps building the site from the RC's tar-ball rather than the "dirty"
> mvn tree post release is safer)

+1

Or use a clean checkout of the tag, which should be the same thing as
the tar-ball.

>
> I think it would only block a release vote if the site showed something
> wrong that also affects the code or jars; e.g. a very broken javadoc or an
> actual RAT violation. Anything else can be fixed post release (but
> comitters to master of course :-)
>
> On 8 Dec 2016 4:21 pm, "Gilles" <gil...@harfang.homelinux.org> wrote:
>
>> On Thu, 8 Dec 2016 12:33:43 +0100, Jochen Wiedmann wrote:
>>
>>> On Thu, Dec 8, 2016 at 9:33 AM, Gilles <gil...@harfang.homelinux.org>
>>> wrote:
>>>
>>> I've just noticed a small problem in the (staged) web site
>>>> submitted for the release of Commons RNG v1.0:
>>>>   http://home.apache.org/~erans/commons-rng-1.0-RC6-site/rat-report.html
>>>>
>>>> Since this must be fixed in the regenerated site will
>>>> not reflect the released version number, why do we
>>>> actually have to vote on the site?
>>>>
>>>
>>> In my opinion: We do not vote on the site. Which is why deficiencies
>>> in the proposed site aren't blocking a release.
>>>
>>> That being said:
>>>
>>> a) The proposed site may be helpful for the release vote, if for no
>>> other reasons than the
>>>      RAT report.
>>>
>>
>> The problem, in this particular case is that the RAT output published
>> in the RC version of the site reports violations on files not part of
>> the release.
>>
>> Gilles
>>
>>
>>> b) The proposal leads to people verifying the site, which they usually
>>> wouldn't do.
>>>
>>>
>>> Jochen
>>>
>>>
>>>
>>> http://www.keystonedevelopment.co.uk/wp-content/uploads/
>>> 2014/10/evolution-of-the-wheel-300x85.jpg
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to