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:
> Thanks to the responses from Nigel/Atin on helping me understand the > goals/problems-with-my-earlier approaches. Missed 'Shyam' in the credits above. Updating that too.
Please discuss this in the maintainers meeting, get consensus, and then file a bug for the infra team. At this point, this is not an action for the infra team, but a proposal. This is not the place for that.
(In reply to Nigel Babu from comment #2) > Please discuss this in the maintainers meeting, get consensus, and then file > a bug for the infra team. At this point, this is not an action for the infra > team, but a proposal. This is not the place for that. Considering that this affects workflow for almost all the developers it is better for it to be discussed where every developer gets a chance to voice their opinion before reaching consensus. Could you point me to a github repo where I can raise this as an issue and then I will be happy to send a mail about this on gluster-devel asking for feedback and improvement.
I don't know of a Github repo where you can file an issue to discuss this. I recommend the maintainers meeting.
(In reply to Nigel Babu from comment #4) > I don't know of a Github repo where you can file an issue to discuss this. I > recommend the maintainers meeting. Most of the RFEs/proposals in any project on gluster get discussed in the open for everyone to see and comment and may be even get a pull request or two. Is there any reason code for infrastructure doesn't follow that model? Unfortunately number of people who attend the maintainers meeting is not a lot, that is the reason for pushing for something other than maintainers meeting. Like you identified it is just a proposal, I am not really sure if larger community is comfortable or not with it. In the worst case I guess I will send it out on gluster-devel, but before that want to understand if there is any special reason for project-infra to be different from other repos in gluster.