[PATCH, v2] wwwdocs: e-mail subject lines for contributions

Richard Sandiford richard.sandiford@arm.com
Wed Jan 22 17:41:00 GMT 2020

"Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com> writes:
> On 21/01/2020 17:20, Jason Merrill wrote:
>> On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote:
>>> On 21/01/2020 15:39, Jakub Jelinek wrote:
>>>> On Tue, Jan 21, 2020 at 03:33:22PM +0000, Richard Earnshaw (lists) 
>>>> wrote:
>>>>>> Some examples would be useful I'd say, e.g. it is unclear in what 
>>>>>> way you
>>>>>> want the PR number to be appended, shall it be
>>>>>> something: whatever words describe it PR12345
>>>>>> or
>>>>>> something: whatever words describe it (PR12345)
>>>>>> or
>>>>>> something: whatever words describe it: PR12345
>>>>>> or
>>>>>> something: whatever words describe it [PR12345]
>>>>>> or something else?
>>>>> Glibc use "[BZ #nnnn]" - obviously BZ becomes PR, but after that, 
>>>>> I'm not
>>>>> too worried.  I'd be happy with [PR #nnnn], but if folk want 
>>>>> something else,
>>>>> please say so quickly...
>>>> [PR 12345] or [PR #12345] is bad, because the bugzilla won't 
>>>> underline it,
>>>> it needs to be either PR12345 word, or PR component/12345 .
>>> ok, lets go with [PRnnnn] then.
>> Doesn't this use of [] have the same problem with git am?
> No, because only 'leading' [] blocks are removed - git mailinfo --help
>> My summaries are often describing the bug I'm fixing, i.e.
>> [PATCH] PR c++/91476 - anon-namespace reference temp clash between TUs.
>> which is also the first line of my ChangeLog entry.  I think you are 
>> proposing
>> [COMMITTED] c++: Fix anon-namespace reference temp clash between TUs 
>> (PR91476)
>> which can no longer be shared with the ChangeLog.
> I was trying to unify this with glibc.  They specify the bug number at 
> the end of the line.
> We can diverge if it's generally felt to be important, but details like 
> this create needless friction for folk working in both communities.

+1 for "component: Summary [PRnnnnn]" FWIW.

PR bz-component/nnnnn works well for C++.  The problem is that so many
other PRs come under tree-optimization and rtl-optimization, which
eat up a lot of subject line characters without narrowing things down
very much.  "cselib: ... [PRnnnnn]" is both shorter and more descriptive
than "PR rtl-optimization/nnnnn - ....", etc.

Same idea for "PR target/nnnnn - ...": you then need to say which target
you mean in the main summary, whereas "aarch64: .... [PRnnnnn]" makes
it easier to keep the main summary short.

Maybe that's just a problem with the bz classification though...


More information about the Gcc mailing list