Hi, On Thu, 30 Apr 2026 at 23:34, Timur Kristóf <[email protected]> wrote: > On 2026. április 30., csütörtök 23:07:12 közép-európai nyári idő Marek Olšák > 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.
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.) 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. I'm pretty sure no-one is suggesting ripping up that social contract, but we should be clear about what we mean. > > 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 > expected failure. 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? Cheers, Daniel
