> 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
>
> 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
