SLING-13321 - send the release result email as part of the vote thread - #58
Open
royteeuwen wants to merge 1 commit into
Open
SLING-13321 - send the release result email as part of the vote thread#58royteeuwen wants to merge 1 commit into
royteeuwen wants to merge 1 commit into
Conversation
royteeuwen
force-pushed
the
feature/SLING-13321-result-email-in-reply-to
branch
2 times, most recently
from
August 31, 2026 19:49
027b34b to
56978e2
Compare
|
A bit late to the party, but can you split the actual feature implementation from the bugfix in the vote counting? Having both in the same PR makes the review harder. |
royteeuwen
force-pushed
the
feature/SLING-13321-result-email-in-reply-to
branch
from
September 6, 2026 11:25
56978e2 to
388fa4d
Compare
Contributor
Author
|
Not late at all — done. Split into a two-PR stack:
No code changed in the split — the two commits were already separate, so each PR is exactly the commit that was already here, and both build and pass on their own. The bugfix is genuinely independent of the feature; it is only stacked rather than parallel because both touch the same tally expression and would otherwise conflict. |
The [RESULT] email is now sent with In-Reply-To and References headers pointing at the [VOTE] email, so a release stays a single thread in the archive and in threading mail clients. The Message-ID needed for those headers is read from the archive search response, which already reports it per email, rather than from the message source. The vote email is now identified by its subject instead of by its position in the thread: the archive search only looks back six months, so a vote opened before that window returns replies only, in which case the first reply used to be dropped from the tally. When no [VOTE] email is found the command warns, keeps the previous behaviour and sends the result email standalone. The thread lookup now uses the full release name, matching the subject that prepare-email generates.
royteeuwen
force-pushed
the
feature/SLING-13321-result-email-in-reply-to
branch
from
September 6, 2026 18:56
388fa4d to
f5a18f7
Compare
|
Member
|
Shouldn’t we rather start adopting https://releases.apache.org/docs/? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 left off, with a different approach to finding the vote email (see below).
Threading the
[RESULT]emailThe
[RESULT]email now carriesIn-Reply-ToandReferencespointing 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.The
Message-IDis read from thestats.luasearch response, which already reports it per email, rather than parsed out of the message source.One open question for reviewers: keeping the
[RESULT]subject prefix follows ASF convention, and threading is correct at the header level. But Gmail also weighs subject similarity, so it may still show the result as a separate conversation there. If the goal is one conversation in the mail client rather than one thread in the archive, the alternative is a plainRe: [VOTE] Release …subject — happy to change it, but that drops a prefix the project has used for years, so it seemed worth asking rather than deciding.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 aRe:-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-emailactually generates.Testing
New
VoteThreadFinderTest;TallyVotesCommandTestgrows from 4 to 8 tests, covering a vote email without aMessage-ID, a vote email outside the lookup window, a thread that cannot be found, and an unresolvable voter. Full suite green at 195 tests.Beyond the unit tests, the command was driven end-to-end in
DRY_RUNagainst the live archive and the live (public) Whimsy roster with only Nexus stubbed. Across five real releases — including a three-module staging repo, and one whose vote predates the lookup window — every generated tally matched the[RESULT]email that was actually sent, and everyIn-Reply-Tomatched the real[VOTE]email'sMessage-ID. TheMailersend path was checked separately to confirmTransport.send()preserves both headers on the wire (onlyMessage-IDis regenerated).