On Fri, Jan 17, 2025 at 12:01:01PM +0100, Uwe Kleine-König wrote:
On Sun, Jan 12, 2025 at 10:06:42PM +0100, Greg KH wrote:
That's fine, the issue is that you are the only ones with "duplicate" commits in the tree that are both tagged for stable, every release.
Isn't a solution as easy as teaching your tooling not to create/accept commits on -next with Cc: stable? This way folks intending to push a change will notice it should go to the fixes branch. And if only afterwards you notice this is a critical fix that should get backported at least the commit that takes more time entering mainline doesn't have the stable tag.
Maybe additionally make sure that Fixes: and revert notices only point to commits that are an ancestor.
The commit is always an ancestor, the "trick" is which one when the ancestor was cherry-picked previously? That's the real problem here..
gre k-h