Due to a recent update on Javascript code a full page refresh on your browser might be needed.
Bug 1366106 - Regression jobs vote on the exact patchset
Summary: Regression jobs vote on the exact patchset
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: GlusterFS
Classification: Community
Component: project-infrastructure
Version: mainline
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nigel Babu
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-11 05:09 UTC by Nigel Babu
Modified: 2017-11-24 09:30 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-24 09:30:58 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description Nigel Babu 2016-08-11 05:09:36 UTC
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.

Comment 1 M. Scherer 2016-08-11 06:57:41 UTC
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.

Comment 2 Nigel Babu 2017-11-24 09:30:58 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.