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.

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to