On Jan 15, 2019, at 6:38 PM, Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx> wrote:
> [Re: linux-next: Fixes tag needs some work in the nfs-anna tree] On 15/01/2019 (Tue 23:12) Takashi Iwai wrote:
>
>> On Tue, 15 Jan 2019 22:41:21 +0100,
>> Chuck Lever wrote:
>>>
>>> Hi Stephen-
>>>
>>> On Jan 15, 2019, at 4:38 PM, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
>>>
>>>> [I am experimenting with checking the Fixes tags in commits in linux-next.
>>>> Please let me know if you think I am being too strict.]
>>>>
>>>> Hi all,
>>>>
>>>> Commit
>>>>
>>>> deaa5c96c2f7 ("SUNRPC: Address Kerberos performance/behavior regression")
>>>>
>>>> has problem with this Fixes tag:
>>>>
>>>> Fixes: 918f3c1fe83c ("SUNRPC: Improve latency for interactive ... ")
>>>>
>>>> The subject should match the subject of the fixed commit.
>>>>
>>>> --
>>>> Cheers,
>>>> Stephen Rothwell
>>>
>>> I shortened the commit title so that the Fixes: line is shorter than 68
>>> characters. I can leave these titles alone if that's preferred.
>>
>> I've sometimes shorted the subject like the above, too, as I find a
>> too long text annoying. Maybe the partial string matching should
>> suffice, especially when it ends with "..." ?
>
> The problem is consistency. Perhaps you shorten at four words. A
> person searches with five words or 70 chars - they never see your commit.
>
> The idea of consistency across the "Fixes:" tags is to allow a level of
> automated processing so that the creators of the stable releases can do
> a lot less manual hands-on processing. They have enough work to do.
My impression was the scripted processing here relies on the commit
ID and not on the patch short description.
The convention of shortening the description with an ellipsis is
already widely used. I think it's reasonable to allow it.
--
Chuck Lever
