Re: Time for amber2?

On 2026. =C3=A1prilis 30., cs=C3=BCt=C3=B6rt=C3=B6k 23:07:12 k=C3=B6z=C3=A9=
p-eur=C3=B3pai ny=C3=A1ri id=C5=91 Marek Ol=C5=A1=C3=A1k=20
wrote:
> The issue is that we don't have a process to deal with CI failures of
> all drivers quickly and effectively. Once we do, it should be smooth
> sailing and we can keep everything.

I agree.

>=20
> First of all, no contributor to shared code is required to fix issues
> in all drivers that their commit breaks. The goal is to stop using the
> pre-merge CI as a justification to force unrelated contributors to
> work on all drivers just because they are contributors. It would be a
> bit exploitative to assume that every contributor must debug all
> drivers that turn red due to a change. I think I understand that well
> because I have debugged 5+ drivers by myself in the past that are not
> my responsibility to maintain, and it does feel exploitative.
>=20
> Therefore, we could establish that each driver/HW combo in pre-merge
> CI has the following options:
> 1) a contact person for prompt CI issue resolution
> 2) unconditional xfail by the author (or removal from pre-merge CI if
> logs lack the information necessary to add xfail)

I think we should establish both of those, in that order.
That is, if the contact person does not reply promptly, just let's add the=
=20
expected failure.

Timur