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.
