>>> but I'm not sure the release
>>> process is right here. The "release.py sign-candidates" suggestion
>>> implies that we expect people to sign all the files but for previous
>>> releases, when I was not release manager, I only signed the Unix
>>> tarballs since that is what I tested. If people sign all the files it
>>> makes it harder to determine whether we have the required number of
>>> Windows/Unix signatures.
>>>
>>> We currently have 5 signatures on the Unix tarballs and 6 signatures on
>>> the Windows zip file but from the mails to dev I believe that 1.7.5
>>> still requires another "real" Windows signature.
>>
>> I've never signed the Windows ZIP files, and don't see why I should when I
>> haven't personally verified their content. I suspect Johan and Paul are the
>> only folks who've really tested the release on Windows.
>
> Yes, I only verified and tested (on Windows) the subversion-1.7.5.zip
> file. This is how I've always done it. I'm happy to sign the
> tarballs too, but I think it makes more sense to return to our de
> facto standard of only signing what we test.

I've always been reluctant to sign the zip file because I don't test it.
As release manager I had to sign eveything since there needs to be some
signature that other testers can verify to ensure they are testing the
right tarballs. So for this release my signature means something
slightly different from previous releases. I've now run my normal
verification tests on Unix but I've still not tested the Windows zip
file. When I posted the call for signatures I'd only run a more basic
"make check".

Is this something we need to make explicit? Perhaps the release manager
should be signing something else? The checksums perhaps? Would that be
strong enough?