Joseph Myers :
> To me, that indicates that using a conversion tool that is conservative in
> its heuristics, and then selectively applying improvements to the extent
> they can be done safely with manual review in a reasonable time, is better
> than applying a conversion tool with more aggressi
On Mon, Dec 30, 2019 at 10:58:05PM +, Joseph Myers wrote:
> > If you guys want to ever finish, you'll need to drop the quest for
> > perfection, because this leads to a) much more work, and b) worse quality
> > in the end.
>
> To me, that indicates that using a conversion tool that is conserva
On Mon, 30 Dec 2019, Segher Boessenkool wrote:
> To make it not be super much work, I'd do the second option: better
> heuristics. Those in Maxim's conversion have been great since over half
> a year, you could borrow some, or peek for inspiration?
Actually, comparing authors between the two con
On Mon, Dec 30, 2019 at 03:36:42PM +, Richard Earnshaw (lists) wrote:
> On 29/12/2019 23:13, Segher Boessenkool wrote:
> > On Sun, Dec 29, 2019 at 11:00:08PM +, Joseph Myers wrote:
> >> fixups in bugdb.py - and that way benefit both from reposurgeon making
> >> choices that are as conserva
On 30/12/2019 15:49, Maxim Kuvyrkov wrote:
>> On Dec 30, 2019, at 6:31 PM, Richard Earnshaw (lists)
>> wrote:
>>
>> On 30/12/2019 13:00, Maxim Kuvyrkov wrote:
On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists)
wrote:
On 29/12/2019 18:30, Maxim Kuvyrkov wrote:
> Below
> On Dec 30, 2019, at 6:31 PM, Richard Earnshaw (lists)
> wrote:
>
> On 30/12/2019 13:00, Maxim Kuvyrkov wrote:
>>> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists)
>>> wrote:
>>>
>>> On 29/12/2019 18:30, Maxim Kuvyrkov wrote:
Below are several more issues I found in reposurgeon-6a
On 29/12/2019 22:56, Eric S. Raymond wrote:
> Richard Earnshaw (lists) :
>> Weak in the sense that it isn't proof given that the user name is
>> partially redacted. There's nothing in the gcc archives that gives a
>> full name either, unfortunately.
>>
>> Yes, it's the most likely match, but there
On 29/12/2019 23:13, Segher Boessenkool wrote:
> On Sun, Dec 29, 2019 at 11:00:08PM +, Joseph Myers wrote:
>> fixups in bugdb.py - and that way benefit both from reposurgeon making
>> choices that are as conservatively safe as possible, which seems a
>> desirable property for problem cases th
On 30/12/2019 13:00, Maxim Kuvyrkov wrote:
>> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists)
>> wrote:
>>
>> On 29/12/2019 18:30, Maxim Kuvyrkov wrote:
>>> Below are several more issues I found in reposurgeon-6a conversion
>>> comparing it against gcc-reparent conversion.
>>>
>>> I am sur
> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists)
> wrote:
>
> On 29/12/2019 18:30, Maxim Kuvyrkov wrote:
>> Below are several more issues I found in reposurgeon-6a conversion comparing
>> it against gcc-reparent conversion.
>>
>> I am sure, these and whatever other problems I may find i
> On Dec 30, 2019, at 3:18 AM, Joseph Myers wrote:
>
> On Sun, 29 Dec 2019, Richard Earnshaw (lists) wrote:
>
>> gcc-reparent is better, but many (most?) of the release tags are shown
>> as merge commits with a fake parent back to the gcc-3 branch point,
>> which is certainly not what happened w
11 matches
Mail list logo