[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZSbUv3Q+K26amgJN@nanopsycho>
Date: Wed, 11 Oct 2023 19:00:47 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, pabeni@...hat.com, davem@...emloft.net,
edumazet@...gle.com, jacob.e.keller@...el.com,
johannes@...solutions.net
Subject: Re: [patch net-next 01/10] genetlink: don't merge dumpit split op
for different cmds into single iter
Wed, Oct 11, 2023 at 06:47:02PM CEST, kuba@...nel.org wrote:
>On Wed, 11 Oct 2023 13:27:05 +0200 Jiri Pirko wrote:
>> >Yeah, we need fixes semantics written down somewhere.
>> >I can do it, sure.
>>
>> I found 2 mentions that relate to netdev regarging Fixes:
>>
>> Quoting Documentation/process/submitting-patches.rst:
>> If your patch fixes a bug in a specific commit, e.g. you found an issue using
>> ``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
>> the SHA-1 ID, and the one line summary.
>>
>> Quoting Documentation/process/maintainer-netdev.rst:
>> - for fixes the ``Fixes:`` tag is required, regardless of the tree
>>
>> This patch fixes a bug, sure, bug is not hit by existing code, but still
>> it is present.
>>
>> Why it is wrong to put "Fixes" in this case?
>> Could you please document this?
>
>I think you're asking me to document what a bug is because the existing
>doc clearly says Fixes is for bugs. If the code does not misbehave,
>there is no bug.
Interesting. Will try to remember :)
Powered by blists - more mailing lists