Re: [MAINTAINERS SUMMIT] Hidden commits from next (aka why maintainers hoard them in backpack)

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

On Thu, Sep 11, 2025 at 11:32:10AM -0400, James Bottomley wrote:
> On Thu, 2025-09-11 at 14:49 +0100, Mark Brown wrote:
> > On Thu, Sep 11, 2025 at 09:18:05AM -0400, James Bottomley wrote:

> > One pattern you see with trees that do this is that some bug is found
> > in -next, the bug is fixed and the patch applied but if the patch is
> > applied to a tree that isn't in -next you still see the bug in -next
> > until the pull request to the upstream tree goes through.  Any
> > incubation that the subtree does before sending their pull request,
> > or delay in taking the pull request from the subtree, shows up in
> > additional time that the bug is visible in -next.

> In theory a fix to a pulled commit, whether separate or rebased, should
> be treated like a bug fix and go up with speed, so is this simply a
> missing rule (or encouragement) for a tree not in -next?

Partly, yes, but the bug isn't always directly in the tree where the fix
is going so it can be a bit less clear and sometimes the delay is on the
pull side (eg, due to holidays or whatever).  It's a lot simpler to just
put the tree in -next.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]