SLING-13321 - do not count the result email of an earlier run as a vote - #59
Draft
royteeuwen wants to merge 1 commit into
Conversation
royteeuwen
changed the title
|
royteeuwen
force-pushed
the
bugfix/SLING-13321-result-email-counted-as-vote
branch
from
September 6, 2026 18:56
56978e2 to
7883471
Compare
The [RESULT] email repeats the tally it announces ("+1 (binding): ..."),
which the "+1" detection counted as a vote cast 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, and put them in the binding
list when they are a PMC member.
Verified against the archive: re-running tally-votes for Resource
Resolver 1.12.16 added Roy Teeuwen as a non-binding voter and for Feature
Model Analyser 2.0.16 added Robert Munteanu as a fourth binding voter,
neither of whom had voted. Both tallies now match the result emails that
were actually sent.
royteeuwen
force-pushed
the
bugfix/SLING-13321-result-email-counted-as-vote
branch
from
September 6, 2026 18:58
7883471 to
89cbefe
Compare
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
1 participant
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.
Split out of #58 at @joerghoh's request, so the vote-counting bugfix can be reviewed separately from the threading feature. Stacked on top of #58.
This is a pre-existing bug, independent of the threading change — it is only stacked on #58 because both touch the same tally expression.
The bug
The
[RESULT]email repeats the tally it announces (+1 (binding): ...), andisPositiveVoteis justcleanup(body).contains("+1"). So once a[RESULT]email for a release is in the archive, the nexttally-votesrun counts it as a vote cast by whoever sent it — the release manager.It is masked whenever the release manager also voted, since both resolve to the same member and the
Setdeduplicates. It bites when they did not.Verified against the archive
Re-running
tally-votestoday against two past releases, before the fix:+1 (non-binding): Roy Teeuwen+1 (non-binding): none+1 (binding): Carsten Ziegeler, Joerg Hoh, Stefan Seifert, Robert Munteanu+1 (binding): Carsten Ziegeler, Joerg Hoh, Stefan SeifertNeither had voted; in the second case the phantom voter lands in the binding list. After the fix both match the
[RESULT]emails that were actually sent, and the two releases where the tally was already correct are unchanged.Note this only affects a re-run — the
[RESULT]has to exist already — so the normalDRY_RUN→AUTOflow is unaffected, and it cannot turn a failed vote into a passing one.The fix
One predicate in the tally filter chain:
isResultEmailstrips any leading reply/forward prefix before checking for[RESULT], so a reply to a result email is excluded too.Testing
testAutoIgnoresResultEmailOfAnEarlierRuncovers both a[RESULT]email and aRe: [RESULT]reply from a member who never voted. Full suite green at 196 tests.