That's why I asked you the intention. I had the impression it would be something to double work what nexus already does on checksums.
Let me see how that works.... and I will put my feedback here. On Wed, Sep 13, 2017 at 5: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 > -- Clebert Suconic
