Re: Time for amber2?

El jue, 14-05-2026 a las 19:13 -0400, Marek Ol=C5=A1=C3=A1k escribi=C3=B3:
> Here's a more detailed description of the problem and a possible
> solution.
>=20
> First, the worst case scenario: A small one-line commit that=E2=80=99s
> correct
> and trivial causes a test failure in the CI. The maintainer of the
> affected driver is asked for help, who concludes that it=E2=80=99s likely=
 a
> HW
> bug and is forwarded to the HW team of the corresponding GPU company.
> Now the management of the GPU company has to allocate staff to
> investigate the failure. 3 months later, we may have a workaround. Or
> not.
>=20
> Second, the scale: The CI has lots of undocumented devices with
> undocumented erratas and drivers with hacks and incomplete
> implementations. (that=E2=80=99s normal for any project) Any of those dev=
ices
> can fail at any time for reasons that might not make sense, and any
> of
> the drivers can fail for random reasons too. It=E2=80=99s not fair to ask=
 the
> contributor to keep everything conformant at every MR. Even if the
> devices were documented with open source implementations (e.g. uarch
> specs, HDL, RTL) and well documented drivers, it=E2=80=99s not reasonable=
 to
> ask the contributor to study them all.
>=20
> Thus, we can=E2=80=99t expect the contributor to be solely responsible fo=
r
> conformance of all devices at every MR in main.
>=20
> It=E2=80=99s useful to keep drivers that have regular contributors confor=
mant
> at most commits in main, but why do we need to keep drivers without
> contributors conformant? If somebody cares about those drivers but
> not
> enough to contribute in main, they can contribute fixes during the RC
> window or on their own schedule.
>=20
> We need a two-tier system:
>=20
> Tier 1:
> - Devices are tested by the CI pre-merge.
> - A contact person is required for CI failure assessment and closure
> within a reasonable time. (if the person is on leave, a backup person
> must be available, or else the device is moved to Tier 2)


I think this makes sense, but we need to agree on what "reasonable
time" means to make sure everyone is on the same page.

Iago

> - Highly recommended: A fully functional drm-shim for each CI job
> with
> a user guide, how to print compiled shaders, etc.
> - Links to HW documentation if available.
> - If maintainers end up xfailing a significant number of failures
> regularly, the device is moved to Tier 2. (due to not using the CI to
> maintain conformance)
>=20
> Tier 2:
> - Pre-merge CI can=E2=80=99t run on the target devices / implementations.
> main
> doesn=E2=80=99t have to work. The quality of release branches is up to
> maintainers. The RC window can be extended.
> - Only unit tests can run per-merge, as well as any deviceless driver
> tests, like the following.
> - Optionally develop deviceless driver validation tests that verify
> driver output (shader instructions, command buffers). LLVM LIT tests
> are the perfect example - they validate all LLVM backends and prevent
> regressions without any physical devices.
>=20
>=20
> Marek
>=20
> On Fri, May 1, 2026 at 5:21=E2=80=AFAM Daniel Stone <[email protected]=
>
> wrote:
> >=20
> > Hi,
> >=20
> > On Thu, 30 Apr 2026 at 23:34, Timur Krist=C3=B3f
> > <[email protected]> wrote:
> > > On 2026. =C3=A1prilis 30., cs=C3=BCt=C3=B6rt=C3=B6k 23:07:12 k=C3=B6z=
=C3=A9p-eur=C3=B3pai ny=C3=A1ri id=C5=91
> > > Marek Ol=C5=A1=C3=A1k
> > > wrote:
> > > > 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
> > There's a bit more nuance in this though. If one set of people is
> > breaking 17 drivers every day because they can't be bothered to do
> > the
> > basics to keep things working and just want to yolo whatever they
> > just
> > thought of into the tree, it's 'unethical' and unfair on the rest
> > of
> > the people who then spend their entire time bisecting and fixing up
> > what the others broke. (Those people then probably get accused of
> > being freeloaders and exploiting the labour of the people breaking
> > everything, because they don't get to spend any time on fun new
> > stuff,
> > given all their time is spent fixing what the others broke.)
> >=20
> > I think we've all taken it as axiomatic that there's a balance to
> > be
> > struck there: don't make others miserable because you can't be
> > bothered spending five minutes thinking about why your new code
> > breaks
> > existing users, but on the other hand you absolutely should expect
> > support from the relevant people to help work it out and resolve
> > it.
> >=20
> > I'm pretty sure no-one is suggesting ripping up that social
> > contract,
> > but we should be clear about what we mean.
> >=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)
> > >=20
> > > 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
> > > expected failure.
> >=20
> > Yeah, that's a pretty obvious baseline. So far it seems to have
> > worked
> > out in the usual way (people know who works on what so it's easy to
> > ping them however), but if that's not working out, maybe someone
> > could
> > suggest a more formal document along the lines of MAINTAINERS or
> > CODEOWNERS or whatever?
> >=20
> > Cheers,
> > Daniel
>=20