Talking about releases... I know there's a policy to archive releases... Tim Bish had once archived a couple of ActiveMQ releases...
It's time to archive a few in Artemis now. (...will look for docs) I could do it next week.. unless someone do it before me. (I'm not really working this week) On Sat, Sep 16, 2017 at 6:14 AM, Robbie Gemmell <[email protected]> wrote: > Yep. I'm not sure exactly how much longer than this it has been the > recommendation, but after noticing we started swapping each component > at Qpid over to using SHA512 checksums in March as they each get > released. Most have changed over now, though still a couple final less > frequently released bits left to go. > > If people are concerned at dropping the SHA1 outright we could always > have both, perhaps for a time as a form of switchover period. I don't > personally think thats really necessary. > > Robbie > > On 15 September 2017 at 21:18, Timothy Bish <[email protected]> wrote: >> On 09/15/2017 03:59 PM, Clebert Suconic wrote: >>> >>> Just for my education. Why you Decided to drop downloading the .sha1 and >>> are creating a new one? >>> >>> All the other downloads we have are using the .sha1? >> >> >> As Robbie stated in the original message the Apache recommendation for >> signatures on the official release artifacts is a sha512 based signature, >> not the older sha1 that is used in the unofficial maven release artifacts. >> >> Refer here: >> http://www.apache.org/dev/release-distribution.html#sigs-and-sums >> >> >>> >>> On Fri, Sep 15, 2017 at 11:56 AM Robbie Gemmell <[email protected]> >>> wrote: >>> >>>> I tweaked the helper script to verify the downloaded tar/zip files >>>> using their downloaded signature, then update the downloaded .md5 file >>>> with filename info so it can verify easily with CLI tools, dropped >>>> downloading the .sha1 and generated a new .sha512, and then at the end >>>> verifies all the checksums as a sanity check (somewhat superfluous for >>>> the SHA512, but doesn't hurt). >>>> >>>> >>>> >>>> https://github.com/apache/activemq-artemis/commit/b7b2960e1f1870246f0c113f56d22cfc0f7a4269 >>>> >>>> If folks are happy with this I can update the instructions at >>>> https://github.com/apache/activemq-artemis/blob/master/RELEASING.md to >>>> reflect the slight process changes needed. >>>> >>>> Robbie >>>> >>>> On 14 September 2017 at 15:32, Clebert Suconic >>>> <[email protected]> wrote: >>>>> >>>>> I thought about checking the sum. Didn't have time. >>>>> >>>>> I would check the files created by nexus Instead of creating new ones >>>>> thought. >>>>> >>>>> >>>>> Feel free to tweak the script. I will be out for a week. I will just >>>>> finish the release and I will be away for a week. >>>>> >>>>> On Thu, Sep 14, 2017 at 5:48 AM Robbie Gemmell <[email protected] >>>>> >>>>> wrote: >>>>> >>>>>> Script looks good, though I'd tweak it a little to cover the eased >>>>>> checksum verification and supplying a SHA512 one (more below). >>>>>> >>>>>> I agree that similar changes would be good for the ActiveMQ 5 releases >>>>>> also, thats the main reason I didn't just detail things on the Artemis >>>>>> 2.3.0 vote thread. >>>>>> >>>>>> Back to the script, I'd suggest tweaking it to add a check that the >>>>>> signature verifies to ensure the downloaded files are ok, then rather >>>>>> than download the .sha1 I'd have it generate a .sha512 file instead, >>>>>> and would similarly update/regenerate the .md5 file to embed filename >>>>>> info so it verifies easily with the CLI tooling. E.g: >>>>>> >>>>>> gpg --verify $theFile.asc >>>>>> md5sum $theFile > $theFile.md5 >>>>>> sha512sum $theFile > $theFile.sha512 >>>>>> >>>>>> Then testers and end users downloading the checksum files can just >>>>>> verify them with the -c flags on the CLI tools, e.g you can check all >>>>>> the checksums with just: >>>>>> md5sum -c *.md5 >>>>>> sha512sum -c *.sha512 >>>>>> >>>>>> On 13 September 2017 at 23:36, Clebert Suconic >>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Ok, fair enough... I can see this as a process improvement. >>>>>>> >>>>>>> I wasn't just understanding what you were proposing clearly enough. >>>>>>> >>>>>>> I just added this script here: >>>>>>> >>>> >>>> https://github.com/apache/activemq-artemis/blob/master/scripts/download-release.sh >>>>>>> >>>>>>> >>>>>>> I didn't update the RELEASE.md yet... >>>>>>> >>>>>>> >>>>>>> I would add that during the release, you use the download-release from >>>>>>> the staged mvn repo using that script into the dev area. >>>>>>> The vote would have the staged download on dev, and we just make a >>>>>>> simple copy from one place to the other.. and remove the previous >>>>>>> thing. >>>>>>> >>>>>>> >>>>>>> But I think this should be also done on ActiveMQ 5 releases. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The thing that threw me of was when you mentioned extra work.. there's >>>>>>> no extra work here :) >>>>>>> It's actually saving me from screwing up eventually, so I take it as >>>>>>> an improvement. >>>>>>> >>>>>>> >>>>>>> On Wed, Sep 13, 2017 at 1:19 PM, Robbie Gemmell >>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> Yes, thats essentially what I mean and do, I have a txt file I keep >>>>>>>> some comments in as notes, and can source as a script to download the >>>>>>>> various tars and signatures from nexus (though it could equally pull >>>>>>>> them from the maven local repo, verifying the Nexus ones is good I >>>>>>>> think), verify the signature, and generate new MD5+SHA512 checksum >>>>>>>> files that include the filename details (it could instead manipualte >>>>>>>> the MD5 one rather than create new). I execute that in a directory >>>>>>>> within a checkout of the dist dev, then commit the files after a >>>>>>>> little validation and open the vote. >>>>>>>> >>>>>>>> The process of putting the files in the dist dev area is mostly the >>>>>>>> same as what will be getting done now for the final release, it just >>>>>>>> uses a different subtree of the same parent dist svn repo, so for >>>>>>>> example you would use a subdir of >>>>>>>> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/ >>>>>>>> before the vote rather than of >>>>>>>> >>>> https://dist.apache.org/repos/dist/release/activemq/activemq-artemis/ >>>>>>>> >>>>>>>> after the vote. >>>>>>>> >>>>>>>> To complete the example, had the files for the recent Artemis 2.3.0 >>>>>>>> vote been in the dist dev area already you would just do something >>>>>>>> like this to complete the release once the vote had passed: >>>>>>>> svn cp -m "add files for activemq-artemis-2.3.0" >>>>>>>> >>>> >>>> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.3.0-rc1 >>>> >>>> https://dist.apache.org/repos/dist/release/activemq/activemq-artemis/2.3.0 >>>>>>>> >>>>>>>> Robbie >>>>>>>> >>>>>>>> On 13 September 2017 at 17:52, Clebert Suconic >>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> I actually see how to make the copy into dev... let me play with it >>>> >>>> a >>>>>>>>> >>>>>>>>> little bit.... >>>>>>>>> >>>>>>>>> On Wed, Sep 13, 2017 at 12:44 PM, Clebert Suconic >>>>>>>>> <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> what about this: >>>>>>>>>> >>>>>>>>>> Currently mvn release and mvn upload will always send the release >>>> >>>> to >>>>>> >>>>>> nexus, >>>>>>>>>> >>>>>>>>>> So what about: >>>>>>>>>> >>>>>>>>>> - we provide an script to artemis to download the correct bits of >>>> >>>> the >>>>>>>>>> >>>>>>>>>> release, the release manager would use that script to perform such >>>>>>>>>> download. >>>>>>>>>> - The release manager would place it on the dev repository Robbie >>>> >>>> is >>>>>>>>>> >>>>>>>>>> mentioning... (that means.. we wouldn't really have an extra step). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On thing I'm not sure how to do is... how to upload it to the dev >>>> >>>> dist >>>>>>>>>> >>>>>>>>>> at https://dist.apache.org/repos/dist/dev/activemq/ >>>>>>>>>> >>>>>>>>>> and how we would make the final move? just a regular copy? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Sep 13, 2017 at 9:49 AM, Robbie Gemmell >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> On 13 September 2017 at 14:35, Clebert Suconic >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Sep 13, 2017 at 9:21 AM Robbie Gemmell < >>>>>> >>>>>> [email protected]> >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> 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. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Actually this is kind of moot. nexus does that check for you. >>>> >>>> You >>>>>> >>>>>> cannot >>>>>>>>>>>> >>>>>>>>>>>> upload a release with a checksum broken. It won't let you close. >>>>>>>>>>>> >>>>>>>>>>>> Like. Last week I had to restart the release once because MVN >>>>>> >>>>>> upload broke >>>>>>>>>>>> >>>>>>>>>>>> the checksum somewhere. >>>>>>>>>>>> -- >>>>>>>>>>>> Clebert Suconic >>>>>>>>>>> >>>>>>>>>>> Whether the files in Nexus are ok isn't sufficient. The archives >>>> >>>> and >>>>>>>>>>> >>>>>>>>>>> checksum files in the dist repo are the mirrorer official release >>>>>>>>>>> artifacts (and strictly only the source ones at that), and Nexus >>>> >>>> cant >>>>>>>>>>> >>>>>>>>>>> check those. There could be a problem deploying those bits for a >>>>>>>>>>> variety of reasons, so we check they are ok. Users downloading the >>>>>>>>>>> release archives also tend to grab the checksums from the dist >>>> >>>> repo >>>>>>>>>>> >>>>>>>>>>> because that is their official source, in order to verify >>>> >>>> downloads >>>>>>>>>> >>>>>>>>>> >> >> -- >> Tim Bish >> twitter: @tabish121 >> blog: http://timbish.blogspot.com/ >> -- Clebert Suconic
