"Richard Earnshaw (lists)" <richard.earns...@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... Richard
