This was less about time, though there is some benefit in that regard, with how much depending on how particular people actually verify the checksums I guess. That said, regardless of how much time difference there actually was, given there is no real cost to doing it (adding line[s] to an existing script), making things easier for testers and more importantly end users eventually downloading the release to use the checksum files for verifying their downloads seems worthwhile to me.
A perhaps more important element is about removing a fragility in the release process that doesn't need to be there. As you say its easy to make mistakes, and using the dist dev repo makes it easier for us to catch issues with the dist repo deployment while we are testing the release, simply by moving some of the existing work a little earlier. Also adopting the recommendation of the distribution policy seemed beneficial to me, the checksums are there for a purpose and following the recommendation to provide a SHA512 checksum improves their use at no significant cost. To be clear, there is no change around the use of Nexus itself, that all stays the way it is, this is purely about basic changes to the existing process of separately putting the official release bits in the dist repo as used for the mirrors and download page etc. Robbie On 13 September 2017 at 13:30, Martyn Taylor <[email protected]> wrote: > I don't think the responses were negative. I don't think the benefit was > made clear and people are questioning whether it's worth the effort. How > much time are we talking about saving here? Seconds, minutes or hours? > Would a reviewer script be helpful for some of this? > > IMO the Artemis release process seems to be working fine, there are quite a > few steps to remember as a release manager and it's easy to make mistakes, > so I would prefer not to change the process unless there's a clear benefit > that warrants it. > > On Wed, Sep 13, 2017 at 10:42 AM, Robbie Gemmell <[email protected]> > wrote: > >> I'm a bit surprised by the negative responses if I'm honest. >> >> There isn't really any significant difference in the amount of work >> for the release manager here. The suggestion mainly just moves the >> step of populating the dist repo to before the vote rather than after, >> using the dev area rather than release area. As part of that entirely >> scriptable action, the checksums could be improved by running some >> commands, simplifying their eventual use both for testers and for end >> users to apply them toward the purpose they exist in verifying >> releases downloaded from the mirrors. Using the dev repo lets folks >> test what is actually going to be released to the dist mirrors later, >> much like the nexus staging repo allows testing the precise maven >> artifacts before they are promoted to release. After the vote there is >> then less moving parts with the release manger (or someone else if >> ever needed) just doing "svn cp <dev-url> <release-url>" to complete >> things, much like clicking the release button in Nexus. >> >> For what its worth, I based the suggestions on having followed similar >> process at Qpid for several years as either release manager or a >> tester. I've release managed a roughly similar number of releases in >> recent years as all the ActiveMQ components combined have had in that >> time, and don't find the suggestions in any way a burden, if anything >> I think they make life easier for everyone including me. >> >> Robbie >> >> On 12 September 2017 at 22:43, Michael André Pearce >> <[email protected]> wrote: >> > 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 >>
