Re: [MAINTAINERS SUMMIT] Time to call it quits for the maintainer summit?
Dave Airlie <[email protected]>
| Newsgroups | dev.linux.lists.ksummit |
|---|---|
| Message-ID | <CAPM=9ty=Kb7rqNg14UCJWz=GJuMbQMZpvsDxfEdgeqePDD1gXw@mail.gmail.com> |
On Tue, 11 Aug 2026 at 01:52, Randy Dunlap <[email protected]> wrote: > > > > On 8/10/26 8:23 AM, Mark Brown wrote: > > I don't think any of that stuff is really what's causing issues with DRM > > externally - for -next the issues I see are the constant cherry picking > > (which I gather is also an issue for stable), and outside of that the > > thing that comes up a lot is that it can be hard to get someone to take > > responsibility for actually applying a patch if you're not a DRM person > > since the responsibility is more diffuse. This can lead to issues like: > > That's even true for simple kernel-doc patches. :( > > > > > https://lore.kernel.org/r/[email protected] > > > > or things where the DRM parts of a cross tree series look like they're > > being ignored. Is there any tag I can put somewhere that for cross-tree patches that are just changing and interface, or cleaning up an API change, that we give you an Ack without getting one, it's really a pointless bit of review theater if something needs changing. or can I offer drm-misc commit rights I suppose, but yes we don't have a good responsible person for acking non-drm patches, and they can fall down the cracks. But if it's something that can get handled via another tree, then I'm usually fine with it just going in via that tree. Dave.