From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55784 invoked by alias); 31 Dec 2019 00:23:32 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 55775 invoked by uid 89); 31 Dec 2019 00:23:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=alternatives, Perfect, quality X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 31 Dec 2019 00:23:31 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id xBV0NI2P022256; Mon, 30 Dec 2019 18:23:19 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id xBV0NHVA022253; Mon, 30 Dec 2019 18:23:17 -0600 Date: Tue, 31 Dec 2019 00:23:00 -0000 From: Segher Boessenkool To: Joseph Myers Cc: "Richard Earnshaw (lists)" , "Eric S. Raymond" , Maxim Kuvyrkov , GCC Development , Alexandre Oliva , Jeff Law , Mark Wielaard , Jakub Jelinek , frnchfrgg@free.fr Subject: Re: Proposal for the transition timetable for the move to GIT Message-ID: <20191231002316.GH3191@gate.crashing.org> References: <20191226111633.GJ10088@tucnak> <5DCEA32B-3E36-4400-B931-9F4E2A8F3FA5@linaro.org> <155B5BFD-6ECF-4EBF-A38C-D6DD178FB497@linaro.org> <20191229224740.GB51787@thyrsus.com> <20191229231342.GF3191@gate.crashing.org> <357e6bf2-55c5-fabc-19e7-457539594258@arm.com> <20191230223651.GG3191@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00542.txt.bz2 On Mon, Dec 30, 2019 at 10:58:05PM +0000, 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 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 aggressive heuristics. Then you need to just completely drop this, and always use , because a large percentage will get that anyway then. Which is fine with me, fwiw: it's correct, and it's a little inconvenient perhaps, but it doesn't really make the result less usable at all. Precisely like weird merges on svn tags that aren't even on a branch. Perfect is the enemy of ever getting a conversion done. > The issues with the reposurgeon conversion listed in Maxim's last comments > were of the form "reposurgeon is being conservative in how it generates > metadata from SVN information". I think that's a very good basis for > adding on a limited set of safe improvements to authors and commit > messages that can be done reasonably soon and then doing the final > conversion with reposurgeon. No, we want to *see* why it would be better than the alternatives, what the differences are. Segher