On Thu, 19 Dec 2019 at 12:42, Richard Earnshaw (lists) <richard.earns...@arm.com> wrote: > > On 19/12/2019 12:35, Jonathan Wakely wrote: > > On Thu, 19 Dec 2019 at 12:33, Richard Earnshaw (lists) > > <richard.earns...@arm.com> wrote: > >> > >> On 19/12/2019 12:23, Jonathan Wakely wrote: > >>> On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists) > >>> <richard.earns...@arm.com> wrote: > >>>> > >>>> On 19/12/2019 09:27, Jonathan Wakely wrote: > >>>>> On Thu, 19 Dec 2019 at 00:02, Joseph Myers <jos...@codesourcery.com> > >>>>> wrote: > >>>>>> > >>>>>> On Wed, 18 Dec 2019, Joseph Myers wrote: > >>>>>> > >>>>>>> On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote: > >>>>>>> > >>>>>>>> I've attached a sample from the start of the fixed list - the full > >>>>>>>> list is far > >>>>>>>> too big to post to give a flavour of how the script currently works. > >>>>>>>> Note > >>>>>>>> that annotations of the form [checkme: ....] in the summary are for > >>>>>>>> diagnostic > >>>>>>>> purposes. These are where heuristics suggest that there's a higher > >>>>>>>> than > >>>>>>>> normal chance that the PR number is incorrect and that manual > >>>>>>>> auditing is > >>>>>>>> recommended. Such annotations would not be appropriate in the final > >>>>>>>> conversion. > >>>>>>> > >>>>>>> Concretely, here is the current list of 664 checkme: annotations where > >>>>>>> something was suspicious about the PR number (either component > >>>>>>> mismatch or > >>>>>>> resolved as INVALID). Would some people like to volunteer to pick up > >>>>>>> sections of this list and, for their section, produce a list of SVN > >>>>>>> revisions (at the end of the checkme line) for which the PR number > >>>>>>> appears > >>>>>>> to be correct, and a list of mappings from SVN revision to correct PR > >>>>>>> number when the PR number appears to be wrong? For any that don't get > >>>>>>> reviewed like that we can easily make the script, for the final > >>>>>>> conversion, decline to add a new summary line for any commit where > >>>>>>> the PR > >>>>>>> number is suspicious. > >>>>>> > >>>>>> Here's a slightly shorter version with 644 checkme: annotations, after > >>>>>> adding a few more component aliases to the script (e.g., no longer > >>>>>> considering it suspicious if the log message says PR g++/something and > >>>>>> that PR is in the component that's actually called c++). > >>>>> > >>>>> Line 18: c++ SVN r116634, looks suspicious, but PR number is correct. > >>>>> Line 326: lto SVN r196613, PR number is correct > >>>>> Line 411: libstdc++ SVN r219147, PR number is correct > >>>>> > >>>>> > >>>>> How do you want the mapping from SVN revision to correct PR to be > >>>>> expressed? > >>>>> > >>>>> Line 19: the correct PR for fortran SVN r120056 is fortran/30238 (not > >>>>> 39238) > >>>>> Line 608: lto SVN r268728 should be PR 87089 (not 87809) > >>>>> Line 616: lto SVN r269799 should be PR 87089 (not 87809) > >>>>> > >>>> > >>>> Best of all would be a pull request on > >>>> https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py > >>>> directly. > >>>> > >>>> Second best would be something like > >>>> > >>>> whitelist: > >>>> > >>>> "<svn-revnumber>", "<svn-revnumber>", > >>>> > >>>> etc, where svn-revnumber is the revision number in svn as reported in > >>>> the checkme above but without the leading 'r' > >>>> > >>>> and > >>>> > >>>> Change: > >>>> > >>>> "<svn-revnumber>": {"PR": "<correct-bugid>"}, > >>>> .... > >>>> > >>>> where svn-revnumber is as before, and <correct-bugid> is the the PR > >>>> number that should have been used. > >>>> > >>>> The above can then be pasted quickly into the script to update it. > >>>> > >>>> R. > >>> > >>> Thanks. I'm working through the first 100 lines in the file then. > >>> > >>> If nobody else starts, I'll take the next 100, and so on. > >>> > >> > >> Great, thanks. > >> > >> It might be useful if someone could start from the other end. The later > >> numbers will be most recent and the ones which are more likely to be > >> relevant to users today. > > > > And less likely to refer to egcs bugs and/or egcs patches from 1997 > > which are harder to find in our mailing lists archives! > > > > Since nobody else has volunteered yet, maybe I should just start at > > the end instead. All I've managed so far is to decide that line 1 is > > too hard to track down and should get a {"summary":"..."} fixup > > instead. > > > > So I'll start with the LAST 100 lines. > > > > Another approach might be to do a quick triage and cull out (whitelist) > the ones that are "obviously correct". You can often tell by reading > the summary itself that it really does correspond to the commit. Then > we'd be left with a shorter list where things really do need further > digging. In the worst case we can just do as Joseph suggests and > implement a policy ignore for those in the final conversion (I already > do that for PR numbers <1000 since there was more than one gnats DB at > that time and the PR numbers just do not line up reliably enough). > > R.
It might be reasonable to assume rtl-optimization and tree-optimization are aliases, and not treat it as suspicious if those two appear mixed up. And anything where bugzilla has component debug or lto and the commit is tree-optimization is probably OK too (that seems to be the case for several so far). We might want to change the component in bugzilla for these: 92324 from c to tree-optimization 91763 from go to lto 91772 from lto to debug 91137 from rtl-optimization to tree-optimization 91445 from c++ to tree-optimization 90577 from middle-end to fortran 90716 from debug to tree-optimization 90273 from debug to tree-optimization 90194 from debug to middle-end
