Hi Thorsten,
On Wed, Oct 16, 2024 at 2:29 AM Thorsten Leemhuis
<regressions@xxxxxxxxxxxxx> wrote:
>
> [CCing Stephen JFYI]
>
> On 16.10.24 07:12, Paul Menzel wrote:
> >
> > Thank you for the patch.
>
> +1
>
> >> Fixes: 81b3e33bb054 ("Bluetooth: btusb: Don't fail external suspend
> >> requests")
> >
> > That commit is not in the master branch,
> > 610712298b11b2914be00b35abe9326b5dbb62c8 is.
>
> Luiz, please allow me to ask: is there a reason why the bluetooth tree
> does not use a dedicated "-fixes" branch like many other subsystems do?
> That would avoid mishaps like the one above and all those "duplicate
> patches in the bluetooth tree" messages Stephen has to sent every few
> weeks
> (https://lore.kernel.org/all/?q=f%3Astephen+duplicate+%22bluetooth+tree%22
> ); reminder, you can have both your -fixes and your -for-next branch in
> linux-next for test coverage.
Not sure I follow, we do have bluetooth tree
(https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git)
for fixes during the RC phase, or are you saying the fixes for RC
shall not be integrated thru bluetooth-next but directly into
bluetooth tree and then once merged they are pulled into
bluetooth-next by rebasing to avoid changing the hash? While possible
this would be hard with our CI which only tests patches against
bluetooth-next tree so by not integrating the RC fixes we may be able
to detect similar changes.
Regarding the duplicate detection, I wonder if that really a problem
or some script failing to detect it is just a hash change, because git
seems fine with those and in most cases it will just say it has
already been applied and move on.
> Ciao, Thorsten
--
Luiz Augusto von Dentz
