[Gluster-infra] [Bug 1635826] New: Improve recheck centos workflow to increase community participation

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1635826

            Bug ID: 1635826
           Summary: Improve recheck centos workflow to increase community
                    participation
           Product: GlusterFS
           Version: mainline
         Component: project-infrastructure
          Assignee: bugs at gluster.org
          Reporter: pkarampu at redhat.com
                CC: bugs at gluster.org, gluster-infra at gluster.org



Description of problem:
At the moment when a test fails spuriously patch submitter evaluates if the
patch has probability of contributing to that failure otherwise they do a
'recheck centos' and moves on without reporting it on gluster-devel which
prevents help getting the problem addressed.

I think it is better for tooling to help increase community participation to
solve the issues in tests before they bubble up and lead to explicit master
lock down.

One approach to increase participation is (This is inspired from review process
the group I worked had in Cisco):
0) Everyone starts out with some agreed-upon 'karma' points

1) Everytime a patch submitter does 'recheck centos' for the test(s) that
caused the spurious failure add the patch-submitter to the list of victims for
that test, if the patch-submitter already exists in the list, increase the
score for that patch-submitter. Decrement 1 karma-point from patch-submitter
(even if multiple tests failed in the build). Send a reply on gerrit with the
karma-points left each time 'recheck centos' is done and nudge to help address
the .t before 'karma' reaches zero by sending a mail on gluster-devel, git
blame on .t can help give hints about the submitter and maintainer etc etc. 

2) When 'karma' reaches zero, then 'recheck centos' should give a helpful
message that helping address the .ts the patch-submitter is affected by will
help regain 'karma points' to be able to do 'recheck centos' again. On patches
which lead to karma loss, don't trigger build even on new versions of the
patch.

3) Let the .t maintainer decide if the test is now fixed or not and
'release-karma-debt <test>' should help patch-submitters regain lost karma.

Feel free to change the details or come up with a new solution, but automated
way is better than the existing manual master lock down.
Benefits of this approach are:
1) Distributes the load of making sure the branch is in good shape to all the
community members.
2) Instills habits in developers to keep branches in good shape and also shows
the way to do things for new comers to the project.
3) Makes the process straight forward for everyone and sets the expectations.
4) No need to worry about removing commit-access for anyone.
5) If there is a .t which is leading to 100% failure and is left un-addressed,
it will be similar to master lock-down and the whole community will work
towards addressing it as a group just like an explicit master lock-down. If it
is not such a bad situation, small groups will help address the problem as a
group.
6) Concentrates on *what* needs to be addressed rather than *who*

Thanks to the responses from Nigel/Atin on helping me understand the
goals/problems-with-my-earlier approaches.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=7gRkudGSk4&a=cc_unsubscribe