They're very often just beaurocratic paperwork pushing because maintainers refuse to give acks for merging patches through a single tree. I guess the snarky intro wasn't clear enough, so elaborate.
Given that we don't even talk about topic branches anywhere else in the docs hopefully this makes things a bit clearer. Cc: Jani Nikula <jani.nik...@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.v...@intel.com> Cc: Lyude Paul <ly...@redhat.com> Cc: Thomas Zimmermann <tzimmerm...@suse.de> Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com> Cc: Maxime Ripard <mrip...@kernel.org> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> --- dim.rst | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/dim.rst b/dim.rst index 60c688d6c027..41d9f0e808b2 100644 --- a/dim.rst +++ b/dim.rst @@ -475,9 +475,13 @@ EXAMPLES Cross-subsystem topic branches ------------------------------ -So you want to send a pull request to another subsystem? Maintainers will likely -get cranky if you ask them to pull a swath of unrelated drm patches, so we'll -use a topic branch based upon Linus' tree with only the relevant patches. +So you want to send a pull request to another subsystem? Frist, you don't want, +it's much simpler to get Acks for merging through a single tree and then maybe +later on backmerge. But if it cannot be avoided, read on. + +Maintainers will likely get cranky if you ask them to pull a swath of unrelated +drm patches, so we'll use a topic branch based upon Linus' tree with only the +relevant patches. First select a suitable *baseline* for your topic branch. For topic branches shared within the gpu/drm subsystem, base it on the latest -- 2.33.0
