On 07/09/2020 18:18, sebb wrote: <snip/>
> Such automation already exists, and is used to generate the VOTE > emails used by many Commons RMs > > $ mvn commons-release:vote-txt Thanks for that. I tried it out on the 1.2.3-RC1 release directory and it looks like it depends on various naming conventions that aren't (currently) used in Commons Daemon. The SVN RC URL looks to be something that can be used going forwards. Just include "-RCn" in the path for the dev tree and remember to rename it to drop the "-RCn" when moving the successful candidate to the release tree. The Git RC tag is easy to change but that means a change in tag format compared to the format that has been used historically. I guess that might cause an issue for users that have written their own tooling to use the git repo directly but that seems like would be a very small number of users and easy for them to fix. The inconsistency bugs me slightly but that is also a minor issue. Is the Git tag configurable at all? The site is the element that gives me the greatest concern. The release should not depend on the site. I don't think that part should be there at all but as a minimum it needs to be optional. Is it? I'll try out the updated path for the dev tree and the git tag for the 1.2.3-RC2 or 1.2.4-RC1 release, which ever comes next. Mark > >> >>> Also the Maven jar: >>> >>> commons-daemon-1.2.0.jar >>> sha1: >>> a3a42da759a94a0522fe4b867ac2f5d0d58cc0a9 >> >> Nexus log messages to the mailing list. E.g. >> >> https://lists.apache.org/thread.html/e3d65d1bb28b631d58d273a15953f365ab6e85a739e7ea26383ac74c%40%3Ccommits.commons.apache.org%3E >> >> and >> >> https://lists.apache.org/thread.html/a3db1d2c76fc02a9076e1d7d611b60c430828c9625f9dde2d9638e1d%40%3Ccommits.commons.apache.org%3E >> >> The staging ID (also in the vote thread) is in the first message and you >> can cross-check the hashes across both messages and with the artefacts >> in Maven Central. >> >> Again I agree that takes work. Again, I would contend it is more >> efficient to do this additional work in the (very) rare cases we need to >> and rather than spend time on the premature optimisation of including >> hashes in release votes. And again, automation would like change that >> equation. >> >> Mark >> >> >>> >>> Sebb. >>> >>> On Mon, 7 Sep 2020 at 14:16, Gilles Sadowski <gillese...@gmail.com> wrote: >>>> >>>> Hello. >>>> >>>>>> [...] >>>>>> see an explanation for why it is necessary >>>>>> (or even helpful) to include artefact hashes in the vote mail. >>>>>> >>>>> I agree and understand all your points here. >>>> >>>> Well, I don't. >>>> An explanation would be useful indeed. >>>> >>>>>> Validating the svn revision for the dist repo [ ... vs ...] >>>>>> comparing the hashes of each file to a hash provided in >>>>>> the vote email. [...] >>>>> >>>>> I was merely trying to offer the opposing perspective of the other folks. >>>> >>>> Aren't we talking about a *requirement*? >>>> Referring to the "executive summary" above (as I understand it), >>>> from Mark's edited text, which information is necessary and sufficient >>>> for a vote? >>>> >>>> Also, isn't this discussion a rehash of my (recurrent) question >>>> about whether the hash checks should be automated? >>>> [I mean, isn't it sufficient that the RM would indicate in the vote >>>> email that the hash values stored in the "dist" area are the same >>>> as those generated by the build?] >>>> >>>> Regards, >>>> Gilles >>>> >>>>>>> [...] >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
