On Fri, 2024-03-22 at 13:18 +0100, Sławek Kapłoński wrote:
> Hi,
>
> Dnia czwartek, 21 marca 2024 20:19:18 CET smooney@redhat.com pisze:
> >
> > 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.
>
> I just want to explain one thing here. It was never my intention to ban anyone or to enforce anything. My email is
> only to ask people to maybe try to improve those recheck comments a bit. But it's totally fine if people in some
> project will not do that at all. They still can do bare rechecks if they want to.
well just looping back to dan's reply to my previosus email.
it seams like the intent this time is to understand why recheck are being done
not to stop peopel rechecking
the irritation i was expressing was because previous time we asked peopel
not to recheck with out a reason was not implemented as asking people to trying
and see if they can fix the underlying problem.
repeating
* STOP DOING BLIND RECHECKS aka. 'recheck'
https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures
in the gate status section of our meeting every week and not actually trying to understand the reasons
people were giving for a recheck was unhelpful and franckly quite annoying.
For reasons for the last 18 month my upstream time has been severly reduced and has almost exclusively
been code review and gate fixes. my persecption of the previous incarndation fo this effort in 2022 was the focus
was not on actully fixing the problems but trackign the rechecks and reducign them to save ci resouce ranther
then improvig ci stablity.
it sound like the intent of the new effort is to actully fix the issues by understanding
why peopel are rechecking and discuraging blind rejects is just a side effect to ensure we
have good data to take action on.
one of the things that was indetiged in the list was kernel panics in the guest
one way to reduce that is if you have a projec ton this list
https://codesearch.opendev.org/?q=cirros-0.5.2&i=nope&literal=nope&files=&excludeFiles=&repos=
please move to cirros 6 or at least 0.5.3
cirros 0.5.2 has a know kernel bug that casues random guest panics that is fixed in both 0.5.3 and the 6.x series
i aware of the ironly of a nova core saying that when nova ahse one freence to a 0.5.2 image but that one is for arm
and does not (that we have seen) hit the issue thats in the x86 one but its on my todo list to fix.
im all for using recheck reasons as a data soruce to try and identify and fix ci issue
but when i saw in our team meeting this week it very triggering as we prviously had agreed to stop doing that as a team
* please avoid bare rechecks (bauzas, 16:12:14)
* ACTION: bauzas to tell about the bare rechecks every week in our
meeting (bauzas, 16:15:26)
ill chat to bauzas about how we can phase this reminder to make it cleare the focus is not about stoping blind recheck
its about understanding why a recheck was required and fixing that issue and providing a reasons is the minimal first
step in that process.
I don't have the exact figures and everything being logged, I'm pretty sure we could eventually find out when and how, but I do remember that before I started to provide this reminder, I explained the reasons behind.
FWIW, the whole nova meeting is a collection of reminders (collecting items for the PTG, triaging bugs, incenting review priorities) that I thought that this other reminder wasn't controversial, and I never heard anyone complaining about it.
Then I stopped providing this reminder for the exact reason that it worked : our bare recheck numbers were dropping.
Now, the TC is pivoting a bit and asking the project leaders to ask the contributors to give better strings for their rechecks. I don't really see it controversial either and I'm open to discuss it on the right media, which is the nova meeting.