Re: [GIT PULL] Immutable tag between the Bluetooth and pwrseq branches for v6.11-rc1

[Krzysztof Kozlowski <krzk@kernel.org>]

On 19/06/2024 20:59, Luiz Augusto von Dentz wrote:
> Hi Bartosz,
> 
> On Wed, Jun 19, 2024 at 3:35 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>
>> On Wed, Jun 12, 2024 at 5:00 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>
>>> On Wed, Jun 12, 2024 at 4:54 PM Luiz Augusto von Dentz
>>> <luiz.dentz@gmail.com> wrote:
>>>>
>>>> Hi Bartosz,
>>>>
>>>> On Wed, Jun 12, 2024 at 10:45 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>>>
>>>>> On Wed, Jun 12, 2024 at 4:43 PM Luiz Augusto von Dentz
>>>>> <luiz.dentz@gmail.com> wrote:
>>>>>>
>>>>>> Hi Bartosz,
>>>>>>
>>>>>> On Wed, Jun 12, 2024 at 3:59 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>>>>>
>>>>>>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>>>>>>
>>>>>>> Hi Marcel, Luiz,
>>>>>>>
>>>>>>> Please pull the following power sequencing changes into the Bluetooth tree
>>>>>>> before applying the hci_qca patches I sent separately.
>>>>>>>
>>>>>>> Link: https://lore.kernel.org/linux-kernel/20240605174713.GA767261@bhelgaas/T/
>>>>>>>
>>>>>>> The following changes since commit 83a7eefedc9b56fe7bfeff13b6c7356688ffa670:
>>>>>>>
>>>>>>>   Linux 6.10-rc3 (2024-06-09 14:19:43 -0700)
>>>>>>>
>>>>>>> are available in the Git repository at:
>>>>>>>
>>>>>>>   git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/pwrseq-initial-for-v6.11
>>>>>>>
>>>>>>> for you to fetch changes up to 2f1630f437dff20d02e4b3f07e836f42869128dd:
>>>>>>>
>>>>>>>   power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets (2024-06-12 09:20:13 +0200)
>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> Initial implementation of the power sequencing subsystem for linux v6.11
>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> Bartosz Golaszewski (2):
>>>>>>>       power: sequencing: implement the pwrseq core
>>>>>>>       power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets
>>>>>>
>>>>>> Is this intended to go via bluetooth-next or it is just because it is
>>>>>> a dependency of another set? You could perhaps send another set
>>>>>> including these changes to avoid having CI failing to compile.
>>>>>>
>>>>>
>>>>> No, the pwrseq stuff is intended to go through its own pwrseq tree
>>>>> hence the PR. We cannot have these commits in next twice.
>>>>
>>>> Not following you here, why can't we have these commits on different
>>>> next trees? If that is the case how can we apply the bluetooth
>>>> specific ones without causing build regressions?
>>>>
>>>
>>> We can't have the same commits twice with different hashes in next
>>> because Stephen Rothwell will yell at us both.
>>>
>>> Just pull the tag I provided and then apply the Bluetooth specific
>>> changes I sent on top of it. When sending to Linus Torvalds/David
>>> Miller (not sure how your tree gets upstream) mention that you pulled
>>> in the pwrseq changes in your PR cover letter.
> 
> By pull the tag you mean using merge commits to merge the trees and
> not rebase, doesn't that lock us down to only doing merge commits
> rather than rebases later on? I have never used merge commits before.
> There is some documentation around it that suggests not to use merges:
> 
> 'While merges from downstream are common and unremarkable, merges from
> other trees tend to be a red flag when it comes time to push a branch

You can rebase, although in a non-automatic way only once you pulled
stable tag/branch from other maintainer but why do you rebase public
branches anyway? That's allowed by linux-next rules but a bit of pain
for everyone so should be avoided.

> upstream. Such merges need to be carefully thought about and well
> justified, or there’s a good chance that a subsequent pull request
> will be rejected.'
> https://docs.kernel.org/maintainer/rebasing-and-merging.html#merging-from-sibling-or-upstream-trees

And the merge request is justified here. Which part of justification is
missing?

> 
> But then looking forward in that documentation it says:
> 
> 'Another reason for doing merges of upstream or another subsystem tree
> is to resolve dependencies. These dependency issues do happen at
> times, and sometimes a cross-merge with another tree is the best way
> to resolve them; as always, in such situations, the merge commit
> should explain why the merge has been done. Take a moment to do it
> right; people will read those changelogs.'
> 
> So I guess that is the reason we want to merge the trees, but what I'm
> really looking forward to is for the 'proper' commands and commit
> message to use to make sure we don't have problems in the future.


Cross tree merges are something incredibly common for Linux kernel thus
I do not understand what is the issue here. Of course obvious rules
apply: you cannot rebase such branch, because you would rewrite the
merged commits. But that's easy to solve by keeping it in topic branch
and then you can perform rebases on own commits and re-merging the tag
from Bartosz.



Best regards,
Krzysztof