Kernel Friends, When you git cherry-pick -x something, do you wipe all the existing SoBs, RBs, and TBs? Adding new SoBs, RBs, and TBs as the cherry picks are reviewed, tested and accepted? I think this makes sense, but we haven't really enforced any kind of cleanup like this in glibc stable branch maintenance, allowing "git cherry-pick -x" to pickup all the existing tags.

@codonell I think you need to ping @gregkh specifically and afaik we don't clear, we only append and point to original commit.

@codonell I don't know of any norms that suggest tags should be cleared in this case. In some subsystems, cherry-picking is a fairly common practice, and having to solicit a new set of tags every time would slow the process down considerably.

@brauner @gregkh A concrete example is this Wind River backport to a stable release branch: https://inbox.sourceware.org/libc-stable/20250711125750.1437303-2-sunilkumar.dora@windriver.com/ which I fetch with b4 (fixes the SoB cherry-picked-from ordering) and then I test, apply my own TB/RB, and push. I think that provenance is clearly identified, so wiping the old tags makes sense. I'm open to any advice where this ran afoul.

@corbet It's not clear to me that any testing for one branch applies to another, and if you have to fix significant merge conflicts then you might need review e.g. rebasing one subsystem but not another and rewriting code to handle missing internal features or cleanups? The original tags should be locatable via the provenance information provided by the "(cherry picked from [commit hash])" note? If anything is slowed down... it's for good reasons?

@codonell It's a judgment call, I guess; there isn't really a firm policy. A significant rebase would generally be seen as needing new testing and review — part of why rebasing unnecessarily tends to be frowned upon. A cherry pick is a rebase of sorts, of course; for me, at least, it would be a matter of just how far a commit has been moved from its native environment. When in doubt, it's going to be best to ask for new reviews and testing.

@corbet I think that makes sense. So the submitter can consciously remove the RBs and TBs and seek them all over again. Which is fine, in the case I'm reviewing today I redid the testing and review.

@brauner @codonell That is correct, in the kernel we do NOT clear any of them out, only add new ones as that would "erase" the work that the original developers/reviewers did on the original change, which isn't a kind thing to do in my opinion.

@gregkh @brauner How do you demarcate what was a review for the original branch and now a review for the new branch? Everything after the "(cherry picked from...)" line?

@codonell @brauner Yes, just add them at the end.

And we don't use the "(cherry picked from..." text in the kernel for stable backports, we do a much larger "commit XXXXXX upstream" at the top of the changelog text to make it easier for tools to catch.

@codonell @gregkh @brauner I understand a tag to apply to the patch, not the resulting tree. So if said patch doesn’t need rework to apply on another branch, it’s fine to keep its tags.