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