From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119243 invoked by alias); 16 Dec 2019 17:40:05 -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 118617 invoked by uid 89); 16 Dec 2019 17:40:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=tooling, five, quality X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (207.211.31.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Dec 2019 17:40:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576518002; 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=CSqscZiWjD7QFaT3JsnUpgPUTYkAjmHeR3NpHSlLV7U=; b=MMP3eDELB+GWPormRXpV/5keljR3PSO7ya1vUFQgb/gIe6wBxjou3iyUxYB4yPK+/iaZyY EkeM5J2aRVhyBVfWI6DC8byJ733gQCQmD41VDnQ1nhF/PEQKskgE/5lphQFbco24EsChcM nIazdjUQaScVv/InkAOQXSdusalm16E= 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-413-p2SO2VC9OyW53vb0U4U8BA-1; Mon, 16 Dec 2019 12:39:59 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 472D98017DF; Mon, 16 Dec 2019 17:39:57 +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 E30C35D9C9; Mon, 16 Dec 2019 17:39:55 +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: "Eric S. Raymond" , Mark Wielaard , Maxim Kuvyrkov , "Richard Earnshaw (lists)" , gcc@gcc.gnu.org Date: Mon, 16 Dec 2019 17:40:00 -0000 In-Reply-To: <20191216153649.GE3152@gate.crashing.org> References: <1685e719-738f-dd4e-c39c-c08e495b202e@arm.com> <9E009921-96EA-44A2-A06A-232711227E69@linaro.org> <20191216133632.GC3152@gate.crashing.org> <20191216135451.GA3142@thyrsus.com> <20191216140514.GD3152@gate.crashing.org> <20191216153649.GE3152@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/msg00248.txt.bz2 On Mon, 2019-12-16 at 09:36 -0600, Segher Boessenkool wrote: > On Mon, Dec 16, 2019 at 02:13:06PM +0000, Joseph Myers wrote: > > On Mon, 16 Dec 2019, Segher Boessenkool wrote: > > > > > Most of us are perfectly happy even with the current git mirror, for > > > old commits. We want "real" git to make the workflow for new commits > > > better. > > > > > > No more delays, _please_. > > > > The timetable is a useful guideline. It should not be our master when > > there are clear improvements with implementations already available; > > waiting to the actual end of stage 3 makes sense (when waiting another > > year would not make sense). When we're talking about something to be used > > for the next 20 years we should make sure to get it right. > > We should not take five years to get it done. > > And the current mirror is "right", already, as Jeff said at the Cauldron > (a minute before we unanymously decided to do the conversion soon; this > is over three months ago already). Yup. I want to convert sooner, not later. I don't mind slipping a little for validation work or because it doesn't line up with our schedules. I don't want to slip for major changes in the tooling. My preference has always been, in order, reposurgeon, Maxim's scripts and the existing mirror. However, I'm confident that all of them will be sufficient for our needs. > > All conversions clearly need more validation work. > > No, I do not agree with that. We have had the opportunity to look at > Maxim's conversions for months already, since before the Cauldron, and > it has been perfectly adequate from the start imnsho, and it has been > improved a little since even. Yet Joseph just indicated today Maxim's conversion is missing some branches. While I don't consider any of the missed branches important, others might. More importantly, it raises the issue of what other branches might be missing and what validation work has been done on that conversion. > > > That missing branches > > in Maxim's conversion could be noted only today clearly shows that > > ... clearly shows that *no one cares* about those branches. > > (and > > conversions with an ad hoc script need much more thorough, trickier > > validation because you don't benefit from knowing the tool has worked for > > other conversions). > > Reposurgeon is ad-hoc as well, and the current implementation is a > complete rewrite, and not proven *at all*. At least Maxim's scripts are > just that: scripts, using some very well-tested very widely used tools > as building blocks. I wouldn't really classify it that way. reposurgeon has significant history. Are we using a rewrite, yes, but there's extensive experience behind it as well as testsuites to validate the work. > > > > If the reposurgeon conversion is not ready now, then it is too late > > > to be selected. > > > > I believe it's at least as ready as Maxim's. > > I do not agree. You say the reposurgeon conversion is not ready today. > Maxim's conversion has been ready for many months. Actually Joseph's position is that reposurgeon is already beyond Maxim's conversion in terms of quality. My interpretation of the messages flying by is they're ironing out some details on the edges, but I don't think those are major intrusive changes. jeff