Re: [MAINTAINERS SUMMIT] Coping with the new-developer flood
Laurent Pinchart <[email protected]>
| Newsgroups | dev.linux.lists.ksummit |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Aug 07, 2026 at 11:20:39AM +0200, Matthieu Baerts wrote: > On 07/08/2026 05:23, Theodore Tso wrote: > > There are some few exceptions, where a fix can't be easily backported > > to the LTS branch, and so a different way of fixing a particular > > serious patch needs to be applied to the LTS branch. But normally > > this will be explicitly stated in the commit description, but we don't > > do that in a structured way, so it might be hard for a non-LLM bot to > > figure this out. > > Good point, but instead of looking at the patch description, it might be > enough to look at the header: an exception could be added for patches > sent to the stable ML with a version in the prefix. > > But back to the idea of checking if the patch can apply: it might not be > easy to deal with all the different trees and branches. There might be > some dependences that are still in review, or applied somewhere but not > in linux-next yet, or conflicts with linux-next, etc. This is an issue that isn't limited to newcomers. As a maintainer, I sometimes don't know what I should apply a patch series on. We have the base-commit and prerequisite-patch-id trailers added by b4 that help a lot there, but not everybody uses them. If a mechanism that flags the issue for newcomers could also ensure that every patch series carries proper base information, that would be a very nice side effect. This may include adding new trailers if some use cases are not currently covered. > Plus note that > Sashiko will generally complain if it cannot find where to apply it. -- Regards, Laurent Pinchart