From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id 2FC6A3858C39; Fri, 10 Sep 2021 04:58:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2FC6A3858C39 Received: by mail-pg1-x530.google.com with SMTP id g184so758309pgc.6; Thu, 09 Sep 2021 21:58:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=aqoeHR9TNCD+8L+90C82Xj7mQJzaONGwbGqGTZUPtkc=; b=mwQ/WsHrOYyBOhl4ZJ4QS5NAzM2FHsM9GIK0NM78K2IWR7clglmhWLmUMeAoKzd2qx oDsv+BTuVwyy2V2pJzRmKtrCPqQyHonuxATi4xMcmFiooX2ZJJLJ7iMJMX7t0S3Y4cmt 4Hezm/RkWSRckiwCw97CJBUvvRecWF0hgf5pDyN4ws2nsM6YUK2Av9no7Wxwa+zfAHrG oYfu2angUSx7/v2UR8fKMhQ57p/NqyfmuTlzloYo+sZb8D9szRiNDA+S7g5PFrn0WYnD zKw5S2K+OKa7ouOnR1RD4uUwAZ99NWwsUEXbJSDpn5/rYo1N+w/0b2lV+fRwZIWQN8pD SF/A== X-Gm-Message-State: AOAM532M/6RNeuAHRZKgNeEdyEUXbrlFaiQyoZSKrtmR7ORcwgb4ahza UUdw1bbrAKkPAcdhG7qOovw= X-Google-Smtp-Source: ABdhPJyF5iMfKbET9b4jaOpK6hbxVxQy/UTk36RklBAN7xeVk2u69Y4s51rTVfHl0P5jnptA0+syLQ== X-Received: by 2002:a63:35cf:: with SMTP id c198mr5849862pga.346.1631249911185; Thu, 09 Sep 2021 21:58:31 -0700 (PDT) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id x26sm3726601pfm.77.2021.09.09.21.58.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Sep 2021 21:58:30 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 5A4F11140070; Fri, 10 Sep 2021 14:28:27 +0930 (ACST) Date: Fri, 10 Sep 2021 14:28:27 +0930 From: Alan Modra To: Andrew Burgess Cc: binutils@sourceware.org, gdb@sourceware.org Subject: Re: Maintenance of top-level files Message-ID: References: <20210908082349.GC1487362@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210908082349.GC1487362@embecosm.com> X-Spam-Status: No, score=-3033.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2021 04:58:33 -0000 On Wed, Sep 08, 2021 at 09:23:49AM +0100, Andrew Burgess wrote: > My question then, is what are peoples thoughts on how these files > should be managed? The question I take it really is: Who has authority to approve patches, and at least some responsibility to respond to bug reports related to these files? I don't think we (binutils + gdb) should take the position that these files are owned by gcc, and thus authority and responsibility fall to the listed gcc build machinery maintainers. That doesn't seem fair or reasonable. The situation with top level files is very different to say, libiberty, where binutils+gdb is unlikely to want changes that are completely uninteresting to gcc. With top level config*, Make*, libtool.m4, lt* and so on we often want changes that aren't interesting to gcc, and vice versa. A model where changes are installed first into one repository and then backported to the other makes sense, I think. So do we want someone appointed top-level build machinery maintainer in binutils+gdb? If so, I nominate Simon Marchi if he's interested. Why Simon? Because in digging through top-level logs, he's the most recent (2018) person to act as a maintainer of those files, commit d0ac1c4488. Before that, there was Ralf Wildenhues in 2010. > Are we going to try and get back in step with gcc? I think we should try to do that. -- Alan Modra Australia Development Lab, IBM