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