linux-next: Fixes tags need some work in the printk tree

linux-next: Fixes tags need some work in the printk tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

Hi all,

In commits

  e5e4c07d9233 ("docs: vmcoreinfo: add lockless printk ringbuffer vmcoreinfo")
  0cfdacd74ad5 ("scripts/gdb: update for lockless printk ringbuffer")

Fixes tag

  Fixes: ("printk: use the lockless ringbuffer")

has these problem(s):

  - No SHA1 recognised

Maybe you meant

Fixes: 254685ef9374 ("scripts/gdb: update for lockless printk ringbuffer")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: Fixes tags need some work in the printk tree

[Petr Mladek]

Hi Stephen,

On Wed 2020-09-02 07:22:54, Stephen Rothwell wrote:
> Hi all,
> 
> In commits
> 
>   e5e4c07d9233 ("docs: vmcoreinfo: add lockless printk ringbuffer vmcoreinfo")
>   0cfdacd74ad5 ("scripts/gdb: update for lockless printk ringbuffer")
> 
> Fixes tag
> 
>   Fixes: ("printk: use the lockless ringbuffer")

The problem is that this commit is not in mainline. It is living
only in printk/linux.git.

> 
> has these problem(s):
> 
>   - No SHA1 recognised

Could we use the SHA1 from the maintainer tree when it would not get rebased?

Or should we rather avoid Fixes: tag referencing commits that are not
in mainline?

I am sorry to bother you with this silly question. I do not see any
hint in Documentation/process/submitting-patches.rst.

Best Regards,
Petr

Re: linux-next: Fixes tags need some work in the printk tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

Hi Petr,

On Wed, 2 Sep 2020 09:26:11 +0200 Petr Mladek <pmladek@suse.com> wrote:
> 
> The problem is that this commit is not in mainline. It is living
> only in printk/linux.git.
> 
> Could we use the SHA1 from the maintainer tree when it would not get rebased?
> 
> Or should we rather avoid Fixes: tag referencing commits that are not
> in mainline?
> 
> I am sorry to bother you with this silly question. I do not see any
> hint in Documentation/process/submitting-patches.rst.

Well, in theory, maintainers trees should not be rebased after they
have been published (except in exceptional circumstances), so using
SHA1s from them should be OK.  Especially if the fixing commit is in
the same maintainers tree (which it should be, right).  It does mean
that maintainers need to be a bit more careful if they do rebase their
trees to update any Fixes tags (or other commit references) that are
affected by the rebase.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: Fixes tags need some work in the printk tree

[Petr Mladek]

On Thu 2020-09-03 06:55:47, Stephen Rothwell wrote:
> Hi Petr,
> 
> On Wed, 2 Sep 2020 09:26:11 +0200 Petr Mladek <pmladek@suse.com> wrote:
> > 
> > The problem is that this commit is not in mainline. It is living
> > only in printk/linux.git.
> > 
> > Could we use the SHA1 from the maintainer tree when it would not get rebased?
> > 
> > Or should we rather avoid Fixes: tag referencing commits that are not
> > in mainline?
> > 
> > I am sorry to bother you with this silly question. I do not see any
> > hint in Documentation/process/submitting-patches.rst.
> 
> Well, in theory, maintainers trees should not be rebased after they
> have been published (except in exceptional circumstances), so using
> SHA1s from them should be OK.  Especially if the fixing commit is in
> the same maintainers tree (which it should be, right).  It does mean
> that maintainers need to be a bit more careful if they do rebase their
> trees to update any Fixes tags (or other commit references) that are
> affected by the rebase.

Thanks a lot for info.

I have rebased the last 5 commits in the printk-rework branch and
added the missing SHAs there.

Best Regards,
Petr