On 9 February 2018 at 15:05, Daniel Gruno <humbed...@apache.org> wrote:
> These are the sigs for the vote:
> MD5: 065197e47fc8854d030b1a67104a827b
> SHA256: d1d09334b6890e76733f8a3996ce573a4b3609582c0298a7912df969f4799b79

Thanks.

> It's all in version control, so you can correlate the vote if need be.

I don't think that's true, because the URL is not immutable.

If the historian only has the released artefact and its hashes, they
cannot trace back to the dist/dev/ repo entry.

> With regards,
> Daniel.
>
> On 02/09/2018 04:00 PM, sebb wrote:
>> On 9 February 2018 at 13:52, Daniel Gruno <humbed...@apache.org> wrote:
>>> On 02/09/2018 12:38 PM, sebb wrote:
>>>> On 9 February 2018 at 10:03, Daniel Gruno <humbed...@apache.org> wrote:
>>>>> Hullo folks, time for a release methinks!
>>>>>
>>>>> This is a vote on the artifacts collected from the tree in the 0.10
>>>>> branch with commit hash a8ea8a044996ba0aea08fe59156edb79cd6f9db8.
>>>>>
>>>>> The tree can be inspected at
>>>>> https://github.com/apache/incubator-ponymail/tree/a8ea8a044996ba0aea08fe59156edb79cd6f9db8
>>>>>
>>>>> The release candidate is available at:
>>>>> https://dist.apache.org/repos/dist/dev/incubator/ponymail/
>>>>>
>>>>> Specifically, this is a vote on
>>>>> https://dist.apache.org/repos/dist/dev/incubator/ponymail/apache-pony-mail-0.10-incubating.tar.xz
>>>>> (md5, sha256 and sig files are provided as well).
>>>>
>>>> The above URL is mutable (indeed will be removed at some point) so it
>>>> would be helpful to include the contents of at least one of the hashes
>>>> in the vote mail.
>>>> Otherwise it won't be follow the provenance of the artefact.
>>
>> "Otherwise it won't be follow the provenance of the artefact."
>> should be
>> "Otherwise it won't be possible to follow the provenance of the artefact."
>>
>> The above still applies.
>>
>>>> Also, why is the file compressed using xz?
>>>> That is a relatively unknown/new format and is unlikely to be
>>>> available on all systems.
>>>>
>>>> By all means provide that as well, but I think sources should be
>>>> provided as gzip and zip for maximum usability.
>>>
>>> xzip (LZMA) has been core in GNU for almost a decade now, and is
>>> preferred to gzip by modern applications (it is what you would use for
>>> distro packages on freebsd and most linux distros).
>>>
>>> It works on Mac as well as Windows (through 7zip), and achieves better
>>> compression than traditional gzip.
>>
>> Both Mac and Windows require 3rd party apps to open the format.
>>
>> The compression ratio is irrelevant here, because the file is small (ca. 1MB)
>>
>>> IOW, there is no barrier to opening this file for our users that
>>> wouldn't exist with gzip.
>>
>> That is not the case with xz which currently appears to be native only to 
>> Linux.
>>
>> Most projects provide zip and tar.gz one or both of which can be
>> opened on Linux, macOS and Windows *without* needing to install a 3rd
>> party app.
>>
>> Yes, they will be a bit bigger, but the formats are much more widely 
>> supported.
>>
>>> With regards,
>>> Daniel.
>>>
>>>>
>>>> -1 because of the above
>>>>
>>>> I've not checked the contents yet.
>>>>
>>>>> Please inspect and vet the candidate and cast your votes accordingly:
>>>>>
>>>>> [ ] +1: Good to go
>>>>> [ ]  0: Meh, either way is fine
>>>>> [ ] -1: Don't release because....
>>>>>
>>>>> Anyone is welcome to vote on this release.
>>>>> PPMC members can cast binding votes for the podling's release decision,
>>>>> and IPMC members may cast binding votes that carry over to the IPMC
>>>>> release vote later. This initial vote will last 72 hours (or less if all
>>>>> possible votes have been cast).
>>>>>
>>>>> With regards,
>>>>> Daniel.
>>>>>
>>>
>

Reply via email to