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.
