On 16.10.24 21:01, Luiz Augusto von Dentz wrote:
> On Wed, Oct 16, 2024 at 2:29 AM Thorsten Leemhuis
> <regressions@xxxxxxxxxxxxx> wrote:
>> 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,
Ahh, I see, you have two different trees, and not different branches in
one tree. Sorry, should have noticed that.
> 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?
I'm no expert here, but subsystems use different strategies afaics. Most
afaics have two branches in one tree or (like you) two trees. Both are
in next. And they only merge the -fixes branch into their -next tree
when there is a need, not regularly (that iirc would upset Linus).
> While possible
> this would be hard with our CI which only tests patches against
> bluetooth-next tree
Can't that be changed? Also: that sounds (but I might be wrong there!)
like -fixes you send to Linus don't get tested independently. Wouldn't
that be better?
> 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.
Stephen might be the better one to answer that, but from his mails and
my understanding of it it's more like "if duplicates happen occasionally
(for example because some change queued for -next turns out needs to be
send through -fixes quickly), it's not a problem. But it shouldn't be
something that happens due to the regular workflow.
I've also seen a few people including Greg complain about Fixes: tags
for commits that don't exist -- which is the case until the duplicate
commit (like the 81b3e33bb054 that triggered this discussion) lands
during the next merge window. But during that time window it can easily
confuse people I guess.
Anyway, maybe I shouldn't have send anything, this is not my area of
expertise. It's just that I noticed the mails from Stephen, the
complains from Greg, and that one discussion at maintainers summit or
LPC where "more trees should have their -fixes branch in next" very
briefly came up.
Ciao, Thorsten
