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
