On Sun, May 16, 2021 at 11:38:10AM +0200, Stefan Wahren wrote: > Hi Fabio, > > Am 16.05.21 um 09:27 schrieb Fabio Aiuto: > > Hi Stefan, > > > > On Sat, May 15, 2021 at 09:10:40PM +0200, Stefan Wahren wrote: > >> Recent commit "staging: vchiq_core: drop vchiq_status from vchiq_init_state" > >> missed to change the return type in the definition. Let's fix this now. > > if this patch fixes something that a previous commit broke, > > it's better adding Fixes: tag > > the mentioned commit is still in next, so a Fixes tag doesn't make sense > to me. Or do i miss something? > This patch doesn't affect runtime so a Fixes tag is not strictly required although probably most of the times we would add it. But it doesn't matter whether or not the commit is in -next or not. The git hash from the fixes tag will remain valid unless Greg rebases (which he seldom does). And if a maintainer rebases their tree, they are responsible for updating the Fixes tag. Fixes tags are useful for backporting because you can see that the bug was introduced in the latest release so the patch doesn't need to be backported. But it's not all about backporting they're also useful for review so we can see why a patch was introduced. Or sometimes I like to look at the fixes tags and see if "cleanup" patches are introducing bugs into staging etc. regards, dan carpenter
