Bug 1366106

Summary:	Regression jobs vote on the exact patchset
Product:	[Community] GlusterFS	Reporter:	Nigel Babu <nigelb>
Component:	project-infrastructure	Assignee:	Nigel Babu <nigelb>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	mainline	CC:	bugs, gluster-infra, mscherer
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-11-24 09:30:58 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.