On Wed, Jan 22, 2020 at 04:05:37PM +0000, Richard Sandiford wrote: > "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.
Yeah, the cselib version definitely looks preferable to me. What if a patch touches more than just the C++ FE, do we want "c,c++:"? Though kernel uses net: sched: act_ctinfo: fix memory leak locking/rwsem: Fix kernel crash when spinning on RWSEM_OWNER_UNKNOWN If a patch touches various spots in the optimizers, maybe we can just go with "tree-opt:" or "rtl:"? Further, I suppose multiple PRs fixed by a single patch would look like: c++: Implement DR 666 [PR57, PR12345] Marek
