On Mon, Sep 7, 2020 at 2:25 PM Rob Tompkins <chtom...@gmail.com> wrote: > > > > > On Sep 7, 2020, at 2:16 PM, Mark Thomas <ma...@apache.org> wrote: > > > > 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
>From a higher level, as a FOSS project, I'd say we want more transparency rather than less, and IMO adding more information like hashes to a VOTE thread makes it easier to track and verify votes, it feels more "open" to me rather than following a bunch of hops to get to the truth; and it's easy to do using "commons-release:vote-txt". Gary > > > > 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. > > This is why I think I need to run through a [daemon] release. To shake out > all these details > > > > > 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 > > > > --------------------------------------------------------------------- > 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
