royteeuwen opened a new pull request, #58: URL: https://github.com/apache/sling-org-apache-sling-committer-cli/pull/58
[SLING-13321](https://issues.apache.org/jira/browse/SLING-13321) asks for the release conclusion email to be part of the original vote thread rather than a standalone message. This picks up where [rombert's WIP branch](https://github.com/apache/sling-org-apache-sling-committer-cli/compare/issue/email-in-reply-to?expand=1) left off, with a different approach to finding the vote email (see below). ## Threading the `[RESULT]` email The `[RESULT]` email now carries `In-Reply-To` and `References` pointing at the `[VOTE]` email, so a release stays one conversation in the archive and in threading mail clients. The subject keeps its `[RESULT]` prefix, as is conventional at the ASF. ``` From: Joerg Hoh <[email protected]> To: "Sling Developers List" <[email protected]> Reply-To: "Sling Developers List" <[email protected]> Date: Thu, 20 Aug 2026 12:47:00 +0200 In-Reply-To: <551383019.0.1787222816913.JavaMail.root@85ae3d6cc5e6> References: <551383019.0.1787222816913.JavaMail.root@85ae3d6cc5e6> Subject: [RESULT] [VOTE] Release Apache Sling Security 1.3.2 ``` `--no-reply-to-vote-email` sends it standalone instead. The `Message-ID` is read from the `stats.lua` search response, which already reports it per email, rather than parsed out of the message source. ## Finding the vote email by subject The vote email used to be identified by position (`skip(1)`). That is not reliable: the archive search only looks back six months, so a vote opened before the start of that window returns replies only, and the first genuine voter was then silently dropped from the tally. The vote email is now identified by its subject — only the original starts with `[VOTE]`, since replies carry a `Re:`-style prefix and a result email carries `[RESULT]`. When no `[VOTE]` email is found the command warns, keeps the previous behaviour and sends the result email unthreaded rather than replying to a reply. The thread lookup now uses the full release name, matching the subject `prepare-email` actually generates. ## A vote-counting bug found along the way The `[RESULT]` email repeats the tally it announces (`+1 (binding): ...`), which the `+1` detection counted as a vote by the release manager who sent it. Re-running `tally-votes` for a release therefore credited the release manager with a vote they never cast, in the binding list when they are a PMC member. It is masked whenever the release manager also voted, since both resolve to the same member. Verified against the archive — re-running `tally-votes` today for two past releases, before the fix: | Release | Generated | Actually sent | |---|---|---| | Resource Resolver 1.12.16 | `+1 (non-binding): Roy Teeuwen` | `+1 (non-binding): none` | | Feature Model Analyser 2.0.16 | `+1 (binding): Carsten Ziegeler, Joerg Hoh, Stefan Seifert, Robert Munteanu` | `+1 (binding): Carsten Ziegeler, Joerg Hoh, Stefan Seifert` | Neither had voted. Both now match what was sent. This is a pre-existing bug independent of the threading change, so the second commit cherry-picks onto master on its own if it would rather be tracked as its own issue. ## Testing New `VoteThreadFinderTest`; `TallyVotesCommandTest` grows from 4 to 8 tests, covering the opt-out flag, a vote email without a `Message-ID`, a vote email outside the lookup window, and a `[RESULT]` email from an earlier run. Full suite is green at 195 tests. Beyond the unit tests, the command was driven end-to-end in `DRY_RUN` against the live archive and the live (public) Whimsy roster with only Nexus stubbed, for four real releases. Every generated tally matched the `[RESULT]` email that was actually sent, and every `In-Reply-To` matched the real `[VOTE]` email's `Message-ID`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
