Sure, they do mostly seem to go away eventually but I'm usually sending
reminders, and apparently at least some of these issues are making it
into upstream pull requests so it seems the reports weren't acted on. I
did ask in the last of those mails if you should be a contact for the
tree given that you seem to be doing a lot of the updates but never
heard back on that - should I make that update?
Given the issues caused by the unusual workflow for the tree I do send a
lot of reports of issues in bluetooth.
Sure, they do mostly seem to go away eventually but I'm usually sending
reminders, and apparently at least some of these issues are making it
into upstream pull requests so it seems the reports weren't acted on. I
did ask in the last of those mails if you should be a contact for the
tree given that you seem to be doing a lot of the updates but never
heard back on that - should I make that update?
Given the issues caused by the unusual workflow for the tree I do send a
lot of reports of issues in bluetooth.
Are you referring to the unusual workflow where fixes are merged to
bluetooth-next first, then to bluetooth (which changes its ID), and
finally merge to net? Changing the order to have Bluetooth first and
then bluetooth-next would require reworking the CI so it could
determine that it is a fix and then use Bluetooth as a base just to
avoid ID changes.
--
Luiz Augusto von Dentz
From: Mark Brown <broonie@kernel.org> Date: 2026-09-15 19:24:30
On Tue, Sep 15, 2026 at 03:16:21PM -0400, Luiz Augusto von Dentz wrote:
On Tue, Sep 15, 2026 at 2:26 PM Mark Brown [off-list ref] wrote:
quoted
Given the issues caused by the unusual workflow for the tree I do send a
lot of reports of issues in bluetooth.
Are you referring to the unusual workflow where fixes are merged to
bluetooth-next first, then to bluetooth (which changes its ID), and
finally merge to net? Changing the order to have Bluetooth first and
then bluetooth-next would require reworking the CI so it could
determine that it is a fix and then use Bluetooth as a base just to
avoid ID changes.
Yes, the routine cherry picking is certainly part of it - it's not so
much the fact that things get moved between branches as the fact that
when you have the same commit is in multiple branches and then build on
top of one or both of them this creates extra conflicts, often harder to
understand, when the branches are merged. The more normal thing would
be to apply once to the right place, or the standard fallback from that
would be to drop the commit from branch A at the time it is moved to
branch B.
You do seem to end up removing the cherry picked commits from their
original branches at some point as part of your workflow (since there
are hardly any duplicate bluetooth commits in mainline) so they do wind
up being moves AFAICT but the duplicates get left sitting there for
quite a while.
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Date: 2026-09-15 19:37:02
Hi Mark,
On Tue, Sep 15, 2026 at 3:24 PM Mark Brown [off-list ref] wrote:
On Tue, Sep 15, 2026 at 03:16:21PM -0400, Luiz Augusto von Dentz wrote:
quoted
On Tue, Sep 15, 2026 at 2:26 PM Mark Brown [off-list ref] wrote:
quoted
quoted
Given the issues caused by the unusual workflow for the tree I do send a
lot of reports of issues in bluetooth.
quoted
Are you referring to the unusual workflow where fixes are merged to
bluetooth-next first, then to bluetooth (which changes its ID), and
finally merge to net? Changing the order to have Bluetooth first and
then bluetooth-next would require reworking the CI so it could
determine that it is a fix and then use Bluetooth as a base just to
avoid ID changes.
Yes, the routine cherry picking is certainly part of it - it's not so
much the fact that things get moved between branches as the fact that
when you have the same commit is in multiple branches and then build on
top of one or both of them this creates extra conflicts, often harder to
understand, when the branches are merged. The more normal thing would
be to apply once to the right place, or the standard fallback from that
would be to drop the commit from branch A at the time it is moved to
branch B.
If I merge to bluetooth, then bluetooth-next won't contain the fixes
meant for stable/rc, so I will need to merge them back to
bluetooth-next immediately it order for our CI to stay current with
the fixes.
You do seem to end up removing the cherry picked commits from their
original branches at some point as part of your workflow (since there
are hardly any duplicate bluetooth commits in mainline) so they do wind
up being moves AFAICT but the duplicates get left sitting there for
quite a while.
Yep, once before sending the pull request for net-next, bluetooth-next
is rebased on top of net-next which brings all the fixes already
merged back to bluetooth-next. Git is absolutely fine with that, I
don't think I ever run into a conflict doing this. Git detects the
fixes already present in net-next as duplicates and eliminates them,
so it really surprises me when you say you are finding conflicts, not
just duplicates.
--
Luiz Augusto von Dentz
From: Mark Brown <broonie@kernel.org> Date: 2026-09-15 22:54:52
On Tue, Sep 15, 2026 at 03:36:50PM -0400, Luiz Augusto von Dentz wrote:
On Tue, Sep 15, 2026 at 3:24 PM Mark Brown [off-list ref] wrote:
quoted
On Tue, Sep 15, 2026 at 03:16:21PM -0400, Luiz Augusto von Dentz wrote:
quoted
Yes, the routine cherry picking is certainly part of it - it's not so
much the fact that things get moved between branches as the fact that
when you have the same commit is in multiple branches and then build on
top of one or both of them this creates extra conflicts, often harder to
understand, when the branches are merged. The more normal thing would
be to apply once to the right place, or the standard fallback from that
would be to drop the commit from branch A at the time it is moved to
branch B.
If I merge to bluetooth, then bluetooth-next won't contain the fixes
meant for stable/rc, so I will need to merge them back to
bluetooth-next immediately it order for our CI to stay current with
the fixes.
Or have your CI merge the branches and run on that (that's a fairly
widely deployed approach).
quoted
You do seem to end up removing the cherry picked commits from their
original branches at some point as part of your workflow (since there
are hardly any duplicate bluetooth commits in mainline) so they do wind
up being moves AFAICT but the duplicates get left sitting there for
quite a while.
Yep, once before sending the pull request for net-next, bluetooth-next
is rebased on top of net-next which brings all the fixes already
merged back to bluetooth-next. Git is absolutely fine with that, I
don't think I ever run into a conflict doing this. Git detects the
fixes already present in net-next as duplicates and eliminates them,
so it really surprises me when you say you are finding conflicts, not
just duplicates.
The issue is not your rebase working, the issue is that until you get
round to doing that rebase anyone that merges both bluetooth and the net
trees (ot Linus' tree for that matter, often the conflicts are with his
tree) sees the duplicated commits and that routinely generates
conflicts. This obviously comes up an awful lot with -next, I am not
rebasing the trees but rather merging them, but do I gather from some
conversations that other people are seeing this as part of their
workflows.
Anyway, to return to my prior question: should you be a contact for the
bluetooth tree?
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Date: 2026-09-16 18:12:42
Hi Mark,
On Tue, Sep 15, 2026 at 6:54 PM Mark Brown [off-list ref] wrote:
On Tue, Sep 15, 2026 at 03:36:50PM -0400, Luiz Augusto von Dentz wrote:
quoted
On Tue, Sep 15, 2026 at 3:24 PM Mark Brown [off-list ref] wrote:
quoted
On Tue, Sep 15, 2026 at 03:16:21PM -0400, Luiz Augusto von Dentz wrote:
quoted
quoted
Yes, the routine cherry picking is certainly part of it - it's not so
much the fact that things get moved between branches as the fact that
when you have the same commit is in multiple branches and then build on
top of one or both of them this creates extra conflicts, often harder to
understand, when the branches are merged. The more normal thing would
be to apply once to the right place, or the standard fallback from that
would be to drop the commit from branch A at the time it is moved to
branch B.
quoted
If I merge to bluetooth, then bluetooth-next won't contain the fixes
meant for stable/rc, so I will need to merge them back to
bluetooth-next immediately it order for our CI to stay current with
the fixes.
Or have your CI merge the branches and run on that (that's a fairly
widely deployed approach).
You do seem to end up removing the cherry picked commits from their
original branches at some point as part of your workflow (since there
are hardly any duplicate bluetooth commits in mainline) so they do wind
up being moves AFAICT but the duplicates get left sitting there for
quite a while.
quoted
Yep, once before sending the pull request for net-next, bluetooth-next
is rebased on top of net-next which brings all the fixes already
merged back to bluetooth-next. Git is absolutely fine with that, I
don't think I ever run into a conflict doing this. Git detects the
fixes already present in net-next as duplicates and eliminates them,
so it really surprises me when you say you are finding conflicts, not
just duplicates.
The issue is not your rebase working, the issue is that until you get
round to doing that rebase anyone that merges both bluetooth and the net
trees (ot Linus' tree for that matter, often the conflicts are with his
tree) sees the duplicated commits and that routinely generates
conflicts. This obviously comes up an awful lot with -next, I am not
rebasing the trees but rather merging them, but do I gather from some
conversations that other people are seeing this as part of their
workflows.
Anyway, to return to my prior question: should you be a contact for the
bluetooth tree?
Yep, you can add me as a contact person for both the bluetooth and
bluetooth-next trees.
--
Luiz Augusto von Dentz
From: Mark Brown <broonie@kernel.org> Date: 2026-09-16 18:27:50
On Wed, Sep 16, 2026 at 02:17:35PM -0400, Luiz Augusto von Dentz wrote:
On Wed, Sep 16, 2026 at 2:15 PM Mark Brown [off-list ref] wrote:
quoted
quoted
Yep, you can add me as a contact person for both the bluetooth and
bluetooth-next trees.
quoted
With your luiz.dentz@gmail.com address?
Yes.
Great, you're added for the bluetooth tree now. I note that I only have
one tree for bluetooth in -next:
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
master
so your fixes tree is not covered, I can easily add that if you tell me
where it is? It'd be good to have it in pending-fixes.
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Date: 2026-09-16 18:30:44
Hi Mark,
On Wed, Sep 16, 2026 at 2:27 PM Mark Brown [off-list ref] wrote:
On Wed, Sep 16, 2026 at 02:17:35PM -0400, Luiz Augusto von Dentz wrote:
quoted
On Wed, Sep 16, 2026 at 2:15 PM Mark Brown [off-list ref] wrote:
quoted
quoted
quoted
Yep, you can add me as a contact person for both the bluetooth and
bluetooth-next trees.
quoted
quoted
With your luiz.dentz@gmail.com address?
quoted
Yes.
Great, you're added for the bluetooth tree now. I note that I only have
one tree for bluetooth in -next:
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
master
so your fixes tree is not covered, I can easily add that if you tell me
where it is? It'd be good to have it in pending-fixes.
The master branch? There's also a for-upstream branch, though I see
it's very old.
We only really use the master nowadays.
OK, that'll be there from tomorrow.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgement of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.