Re: Proposal for the transition timetable for the move to GIT

2019-12-30 Thread Eric S. Raymond
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

Re: Proposal for the transition timetable for the move to GIT

2019-12-30 Thread Segher Boessenkool
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

Re: Proposal for the transition timetable for the move to GIT

2019-12-30 Thread Joseph Myers
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

Re: Proposal for the transition timetable for the move to GIT

2019-12-30 Thread Segher Boessenkool
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

Re: Proposal for the transition timetable for the move to GIT

2019-12-30 Thread Richard Earnshaw (lists)
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

Re: Proposal for the transition timetable for the move to GIT

2019-12-30 Thread Maxim Kuvyrkov
> 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

Re: Git conversion: fixing email addresses from ChangeLog files

2019-12-30 Thread Richard Earnshaw (lists)
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

Re: Proposal for the transition timetable for the move to GIT

2019-12-30 Thread Richard Earnshaw (lists)
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

Re: Proposal for the transition timetable for the move to GIT

2019-12-30 Thread Richard Earnshaw (lists)
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

Re: Proposal for the transition timetable for the move to GIT

2019-12-30 Thread Maxim Kuvyrkov
> 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

Re: Proposal for the transition timetable for the move to GIT

2019-12-30 Thread Maxim Kuvyrkov
> 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