The centos regression and netbsd regression vote on an exact patchset number. This works okay 90% of the cases. But we run into ad edge case:
1. Patchset 1 has Verified +1 added triggering regression jobs.
2. Edit commit message, creating Patchset 2.
3. Jenkins reports success/failures on Patchset 1. Since it's to an older commit, the patch ends up not being counted.
We need to figure out a way to ensure it's counted *if* the changes were superficial or have the discipline to not change commit messages until regression jobs have reported back.
I suspect the biggest issue is to decide "what is superficial change". It seems safe to keep the vote if the only change was the commit message, but more than that seems not a good idea, IMHO.
I've had to think about this and work with Jenkins. There's no easy way to solve this. So I'm going to close this one.