On Sun, 2014-06-29 at 15:04 +0100, sebb wrote: > On 29 June 2014 14:42, Oleg Kalnichevski <[email protected]> wrote: > > On Sun, 2014-06-29 at 14:24 +0100, sebb wrote: > >> On 29 June 2014 12:55, Oleg Kalnichevski <[email protected]> wrote: > >> > On Sun, 2014-06-29 at 01:14 +0100, sebb wrote: > >> >> On 28 June 2014 09:28, Oleg Kalnichevski <[email protected]> wrote: > >> >> > On Sat, 2014-06-28 at 00:24 +0100, sebb wrote: > >> >> >> On 27 June 2014 20:44, Oleg Kalnichevski <[email protected]> wrote: > >> >> >> > On Fri, 2014-06-27 at 17:56 +0100, sebb wrote: > >> >> >> >> I'm inclined to agree with Gary that the site is important as a > >> >> >> >> help > >> >> >> >> when reviewing the RC. > >> >> >> >> > >> >> >> >> Apart from the RAT report, there is the Clirr report. > >> >> >> >> > >> >> >> > > >> >> >> > What's wrong with 'mvn clirr:check', which is a part of the release > >> >> >> > process anyway? One is welcome to add RAT maven plugin as well. > >> >> >> > >> >> >> My point is that these reports should be part of the RC VOTE. > >> >> >> > >> >> > > >> >> > Right, and 'mvn clirr:check' gives you exactly that report. Voting on > >> >> > some pre-generated report or website is _idiocy_ because there is no > >> >> > way > >> >> > of telling if those reports actually match the release artifacts voted > >> >> > upon. > >> >> > >> >> There's also no way to be sure that the binaries agree with the source. > >> > > >> > And here we go. Voting on binary artifacts is equally stupid. The only > >> > >> Sorry, that was a bad analogy. > >> > >> But there are some aspects of binary artifacts that can - and should - > >> be checked. > >> > >> For example, sigs, hashes, NOTICE and LICENSE. > >> Ensuring that the binary artifacts don't contain bundled items that > >> should not be present. > >> Ensuring that jars have suitable MANIFEST entries > >> > > > > Which one should do by generating those binary artifacts from the > > source. > > Huh? > How does that help? > > The binary artifacts in the release vote are the ones that are going > to be published via the ASF mirrors. > So they are the ones that need checking to ensure that nothing has > gone wrong with the build. > > Any build others may do is not directly relevant to the artifacts that > are proposed for release. >
What we release is a source tarball. Binary artifacts are distributed merely for convenience of users. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
