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: b...@gluster.org Reporter: pkara...@redhat.com CC: b...@gluster.org, gluster-infra@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 _______________________________________________ Gluster-infra mailing list Gluster-infra@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-infra