im not aware of all th things on the TCs plate right now but this feels to me liek somethign we should not be spending time on. the contributor that do most of the work day to day already know this policy. for new continuator we try to tell them about it when we see bare rechecks but this always feels like we are perching to the choir. i think it would be better to just stop tracking this and i don't think enforcing this in code is a good thing either. people that don't care will just work around it so unless we are going to soft ban an account for a few days or something like that i dont think it will have much impact. i dont think we need to take the ban hammer out to people that do bare rechecks but after a few years of advertising this policy now this feels more like sapm to me then actully something that will have a positive effect. maybe im just being cynical but if we make recheck hard people will just work around it by maing a trivial change to the patch or hitting the rebase button in the ui instead and get the same effect... that my perspective anyway but i dont think this help our comuntity be more welcoming or enjoyable to work with. ci is a share resouce we should not squander but this topic just draing my energy when i see it come up in team meeting or the mailing list. On Thu, 2024-03-21 at 20:39 +0300, Maksim Malchuk wrote:
Sven, bare rechecks can't be disabled, because it's hard to check if the meaningful reason is provided. Enforcing specify the reason will lead to the commands like "recheck failed" or "recheck lets check" etc.
On Thu, Mar 21, 2024 at 7:10 PM Sławek Kapłoński <skaplons@redhat.com> wrote:
Hi,
Dnia czwartek, 21 marca 2024 16:23:21 CET Jeremy Stanley pisze:
On 2024-03-21 15:56:42 +0100 (+0100), Sven Kieske wrote: [...]
There must be a specific reason why bare rechecks are allowed at all? Why don't we simply enforce that there always must be a reason given?
Of course we can't enforce a meaningful reason being stated, but this is already the case now, so it would not get worse if we just disabled the possibility for bare rechecks, no? [...]
There was a time when we did exactly that, it lasted several years and the end result did not yield any measurable improvement in data quality. In fact, at one point we got restrictive enough to require bug numbers and the outcome was that people either made up nonexistent bug numbers or just put in any old bug they knew the number for regardless of whether it was related to the failure.
Yes it's been a while so I can't say for certain that the results would be the same if we tried again, but I don't have a good reason to believe it would turn out any different. Also, bear in mind, the pipeline trigger patterns apply to the entire Zuul tenant used by the OpenStack project, which is currently shared by any other projects outside OpenStack's governance, so if this change were enforced (again) it would disrupt their contributors' workflows as well. -- Jeremy Stanley
I agree with Jeremy here. We know that enforcing don't really work well and that's why we are trying to educate more :)
-- Slawek Kaplonski Principal Software Engineer Red Hat