I'm -0 on this.

I'm not against it if people want it, but also I don't see if it adds that much 
to warrant the effort.

 e.g. If I had to do the work I prob wouldn't want to have the extra burden. At 
most I would just update the checksum (though I don't think this is end of the 
world right now either, I know plenty of org/projects still using md5 hash only 
still)

As someone who's been active since the new year and tested now a few releases 
it hasn't been difficult getting binaries or artifacts and validating them.


Cheers
Mike





Sent from my iPhone

> On 12 Sep 2017, at 22:03, Clebert Suconic <[email protected]> wrote:
> 
> What is the point on adding extra steps on verifying signatures and hashes?
> Nexus won't let us deploy anything if it has a bad hash?
> 
> It seems additional burecractics that could be automated in Nexus. Or
> whatever ever replaces it if you are concerned about the future.
> 
> I have been following other projects and their processes are even leaner
> than ours.
> 
> On Tue, Sep 12, 2017 at 4:41 PM Clebert Suconic <[email protected]>
> wrote:
> 
>> -1 to change the process.
>> 
>> +1 to add scripts to the reviewer.
>> 
>> That is we improve the process of reviews. But I don't think we need to
>> change how this is released.
>> 
>> 
>> 
>> 
>>> On Tue, Sep 12, 2017 at 12:36 PM Daniel Kulp <[email protected]> wrote:
>>> 
>>> Just to be clear…
>>> 
>>> This proposal creates more work for the release manager prior to starting
>>> the vote but in hopes of reducing the work for the reviewers.   It’s a bit
>>> more than a “mvn release:prepare ; man release:perform”.  Some of the extra
>>> work can obviously be scripted, but it is still a bit more to do.
>>> 
>>> That said,  script provided to the reviewer could accomplish the same
>>> things using the current staging location/setup.
>>> 
>>> Anyway, I’m -0 to the idea.    Getting folks to actually be a release
>>> manager is hard enough, why make it even more work.    Since I haven’t been
>>> a release manager for an ActiveMQ release in a while, I certainly wouldn’t
>>> hold up the idea though.
>>> 
>>> Dan
>>> 
>>> 
>>> 
>>>> On Sep 12, 2017, at 9:49 AM, Robbie Gemmell <[email protected]>
>>> wrote:
>>>> 
>>>> Hi folks,
>>>> 
>>>> I mentioned on the recent Artemis 2.3.0 vote that I had some suggested
>>>> changes for the release process improvements, not just for Artemis but
>>>> for other components too, and would send a mail later.
>>>> 
>>>> The short version is there are three main things I'd like to suggest
>>>> as improvements, both for folks testing+voting, and end users
>>>> downloading the release later:
>>>> - Using the dist dev repo for publishing bits for folks to test and
>>> vote on.
>>>> - Providing checksum files in the dist repo which verify more easily
>>>> with the related tools.
>>>> - Use SHA512 rather than SHA1 for checksums in the dist repo.
>>>> 
>>>> # Dist dev repo for votes
>>>> 
>>>> Currently the ActiveMQ votes for the Java components tend to link to
>>>> the artifacts in the nexus staging repo. I think using the dist dev
>>>> repo (https://dist.apache.org/repos/dist/dev/activemq/) to publish the
>>>> bits under vote would be an improvement. Its easy for folks to grab
>>>> all the files at once, helps ensure that what people test is actually
>>>> what will end up in the dist release repo later, and it simplifies the
>>>> eventual release step to a single svn remote copy command.
>>>> 
>>>> # Provide more easily verifiable checksum files in dist release repo
>>>> 
>>>> Currently, the checksum files provides in the dist release repo are
>>>> just the ones from nexus. These lack filename information and so you
>>>> cant verify them as easily with tools. Files which contain the
>>>> filename detail can be verified quickly and even grouped in a single
>>>> shot with the checksum tools, e.g "md5sum -c *.md5". For the MD5 and
>>>> SHA1 cases they could be prepared either by manipulating the existing
>>>> files taken from nexus to add the names, or simply generating the
>>>> checksums again with the tools and manually verifying them the same
>>>> way everyone currently needs to.
>>>> 
>>>> # Provide SHA512 checksum files in the dist repo
>>>> 
>>>> The release distribution policy has suggested using SHA512 for some
>>>> time now, I think it would be good to make the switch for the files
>>>> provided in the dist repo.
>>>> http://www.apache.org/dev/release-distribution.html#sigs-and-sums
>>>> 
>>>> Robbie
>>> 
>>> --
>>> Daniel Kulp
>>> [email protected] - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>> 
>>> --
>> Clebert Suconic
>> 
> -- 
> Clebert Suconic

Reply via email to