From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33465 invoked by alias); 16 Dec 2019 22:14:03 -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 33445 invoked by uid 89); 16 Dec 2019 22:14:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=black X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (207.211.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Dec 2019 22:14:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576534439; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UpPfbrdlOPwxmcXQuh80mG9QzCX5lf1YUN4M3PA/cbk=; b=V+s1jH1wkQivIVp76aO8gWZD8orLCzXbFPrfG7JUWj9J4A7YTzISquIxrd9A//MYNpJAnn WYWxsyhKkk8ItQyXA4jHkiiMzmxsUadlkYiDMsWOLKM1hXM/VuVy3r/b0g/CpZRWCMyESO hx4pjT+zbD6Tc47MHRPWEDbSB2nKk/0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-397-wJELPNh1N0O3dijixOPeyA-1; Mon, 16 Dec 2019 17:13:56 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6E331DC20; Mon, 16 Dec 2019 22:13:54 +0000 (UTC) Received: from ovpn-112-27.phx2.redhat.com (ovpn-112-27.phx2.redhat.com [10.3.112.27]) by smtp.corp.redhat.com (Postfix) with ESMTP id F3BBA6136C; Mon, 16 Dec 2019 22:13:50 +0000 (UTC) Message-ID: Subject: Re: Proposal for the transition timetable for the move to GIT From: Jeff Law Reply-To: law@redhat.com To: Segher Boessenkool , Joseph Myers Cc: Mark Wielaard , Maxim Kuvyrkov , "Richard Earnshaw (lists)" , gcc@gcc.gnu.org, esr@thyrsus.com Date: Mon, 16 Dec 2019 22:14:00 -0000 In-Reply-To: <20191216215927.GG3152@gate.crashing.org> References: <1685e719-738f-dd4e-c39c-c08e495b202e@arm.com> <9E009921-96EA-44A2-A06A-232711227E69@linaro.org> <0fb81074d87c96b3312565800b8bfc25cfcbe179.camel@redhat.com> <20191216215927.GG3152@gate.crashing.org> User-Agent: Evolution 3.34.2 (3.34.2-1.fc31) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00253.txt.bz2 On Mon, 2019-12-16 at 15:59 -0600, Segher Boessenkool wrote: > In particular, we should look carefully at the commit > > attributions in both conversions and Maxim's may well give ideas for > > improving the reposurgeon changelogs command (Richard came up with three > > ideas recently, which I've just filed in the reposurgeon issue tracker). > > But I also think: > > > > * reposurgeon is a safer approach than ad hoc scripts, provided we get > > clean verification of basic properties such as branch tip contents. > > I totally do not agree. Black boxes are not safe. *New* black boxes > are even worse. > > I trust scripts that have low internal complexity much better. Perhaps. But there's also limits to what scripts can do. > > There is absolutely no reason to trust a system that supposedly was > already very mature, but that required lots of complex modifications, > and even a complete rewrite in a different language, that even has its > own bug tracker, to work without problems (although we all have *seen* > some of its many problems over the last years), and at the same time > bad-mouthing simple scripts that simply work, and have simple problems. I'd disagree. THe experience and testsuites from that system are a significant benefit. > > > * Richard's improvements to commit messages are a great improvement to the > > resulting repository (and it's OK if a small percentage end up misleading > > because someone used the wrong PR number, sometimes people use the wrong > > commit message or commit changes they didn't mean to and so having some > > misleading messages is unavoidable). > > As long as the original commit message is kept, verbatim, and you only > add a new summary line, all is fine. If not -> nope, not okay. Sorry, have to disagree here. I think what Richard has done is a significant step forward. > > > * As we're part of the free software community as a whole rather than > > something in isolation, choosing to make a general-purpose tool work for > > our conversion is somewhat preferable to choosing an ad hoc approach > > because it contributes something of value for other repository conversions > > by other projects in future. > > This, I don't agree with at all either: having some lean-and-mean > scripts that worked for the GCC conversion will be at least as helpful > for another conversion as a "general" tool that first requires you to > build a custom machine before you can use it properly, would be. > > > Anyway: yes, please verify all conversion candidates for your criteria. > Thanks! And if they're the same, then I'm still going to prefer reposurgeon. So unless there's something Maxim's scripts are getting right that aren't by reposurgeon, then reposurgeon is the right choice. jeff