[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <89bb83ec-200c-4ed6-bfd8-ac55375e4ee1@lunn.ch>
Date: Tue, 7 Oct 2025 14:18:51 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Luiz Augusto von Dentz <luiz.dentz@...il.com>
Cc: Rob Herring <robh@...nel.org>,
Ariel D'Alessandro <ariel.dalessandro@...labora.com>,
andrew+netdev@...n.ch, conor+dt@...nel.org, kernel@...labora.com,
krzk+dt@...nel.org, angelogioacchino.delregno@...labora.com,
kuba@...nel.org, devicetree@...r.kernel.org,
linux-bluetooth@...r.kernel.org, davem@...emloft.net,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
pabeni@...hat.com, edumazet@...gle.com
Subject: Re: [PATCH v3] dt-bindings: net: Convert Marvell 8897/8997 bindings
to DT schema
> > > > Reviewed-by: Rob Herring (Arm) <robh@...nel.org>
> > > >
> > > > You'll probably have to resend this after rc1.
> > >
> > > In that case I'd like to have a Fixes tag so I can remember to send it
> > > as rc1 is tagged.
> >
> > A Fixes tag is not appropriate for a conversion to DT schema.
>
> Ok, but then how do you justify merging it for an RC? Or I'm
> misunderstanding and that should just be merged to bluetooth-next and
> wait for the next merge window? In that case I can just merge it right
> away.
Most subsystems don't accept new patches during the merge window
because they will need to do a rebase when -rc1 is pushed. And
rebasing of patches is frowned upon.
By requesting the developers to repost after -rc1 is out, and the
subsystem tree has been updated to -rc1, the Maintainers avoids the
rebase, and pushes the work to the developer to rebase and retest,
leaving the Maintainers to do more useful work.
Andrew
Powered by blists - more mailing lists