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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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

On Thu, 2025-09-11 at 17:02 +0100, Mark Brown wrote:
> 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.

There is a downside to putting the upper and lower trees in -next,
particularly if they're out of sync like you describe above in that it
will likely cause a conflict.  Now Stephen usually resolves these but
it's going to cause him way more problems if we adopt this approach.

Regards,

James


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]