From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +tK9J098VWMvyw8AWB0awg (envelope-from ) for ; Sun, 23 Oct 2022 13:39:27 -0400 Received: by simark.ca (Postfix, from userid 112) id 93FAA1E112; Sun, 23 Oct 2022 13:39:27 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=agXaoYO8; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 196F31E0D5 for ; Sun, 23 Oct 2022 13:39:27 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4CA6F3851C1F for ; Sun, 23 Oct 2022 17:39:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4CA6F3851C1F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1666546766; bh=E7BFVGjo9tfAmPhSFVO1fCU9eib4oGpGPvtew7jlAPA=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=agXaoYO8YNkBVPPZCaiBq96uHsGGzfwmUE0PEQu3EcathvKuGSxyXq16bRxvyetw6 8X2fTyggLN4RL/uc+Hcudi4SRMAGwomxr0QOtvmd3It+hG/1Wak5cYuR2pOExDKPTL Yyj61ws3YsRoQ593r39gkxeUolZxnzhcLlLXIp38= Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) by sourceware.org (Postfix) with ESMTPS id A7F293857030; Sun, 23 Oct 2022 17:38:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A7F293857030 Received: by mail-il1-x136.google.com with SMTP id 7so1255188ilg.11; Sun, 23 Oct 2022 10:38:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=E7BFVGjo9tfAmPhSFVO1fCU9eib4oGpGPvtew7jlAPA=; b=dono7kzAvtfwTS23ekbBE2etkRlimViOF7AxWMP7z+dx3xDoW8tWYSy8Vz00LvSQAq Ps7VkbEIaesmExVBAdJWNNwt5EfLYROijb6UcBIeNtkR4M9w0O3xgIs+keJ+TU/JdSG3 SKZrmVEaHLlaKmLWNzMjlbTEyp+4uYet+4xKzauoLPLHaplDVSwwyIrTyCuhW85t2mKE 7089AGVmfI+SUjDo8lgF6dv+YWAbHCvpneoQxzok36MvHPoUYEBC/hiyG72RZtHRO++/ yySXA9qDs58b9H1Nr+VwvKfxrvXd4R3jDTHGuS0iqUppDCyEoVKgFhjVGC+7EuUoIvik A3HA== X-Gm-Message-State: ACrzQf3V0lh85wD0aXyNfuLJemgCt+ignJkN+lSRXsv2AOGXb1ZvWNDT OsJPp62kRmuPMT9N1zDAVpA= X-Google-Smtp-Source: AMsMyM5Mte2NH6Y++OsM7SULwm4hrhx2AsjW+mqfQGvpTxm9pOVlfghP4TIt0wvVRWOg6sGqvAnvPQ== X-Received: by 2002:a05:6e02:1688:b0:2fc:50d7:6966 with SMTP id f8-20020a056e02168800b002fc50d76966mr19046717ila.51.1666546731700; Sun, 23 Oct 2022 10:38:51 -0700 (PDT) Received: from [172.31.1.18] (65-130-77-9.slkc.qwest.net. [65.130.77.9]) by smtp.gmail.com with ESMTPSA id x7-20020a026f07000000b00363aec42c13sm6522485jab.65.2022.10.23.10.38.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 23 Oct 2022 10:38:51 -0700 (PDT) Message-ID: <40ac1e4b-a873-df1e-ad38-38a3b8fbae2b@gmail.com> Date: Sun, 23 Oct 2022 11:38:49 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: Toolchain Infrastructure project statement of support Content-Language: en-US To: "Frank Ch. Eigler" , Siddhesh Poyarekar References: <2513b668-9ebd-9e78-7263-dc24f4a9558a@redhat.com> <20221013182529.sm76fysq37sv754x@cgf.cx> <9c0a9111-07b1-3617-c5c8-4b12e616f985@gotplt.org> <7abeb179-2c05-eee9-bd68-3b5f8a11bd32@gotplt.org> <87zgdmyg30.fsf@fsf.org> <230909ee-fb2c-cca0-abbe-fd7d6434efab@gotplt.org> <20221023151640.GA8034@redhat.com> <0bac951e-8f5e-deb6-c126-26d5fbd0bbfe@gotplt.org> <20221023170933.GB8034@redhat.com> In-Reply-To: <20221023170933.GB8034@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: , From: Jeff Law via Gdb Reply-To: Jeff Law Cc: gcc@gcc.gnu.org, Overseers mailing list , libc-alpha@sourceware.org, gdb@sourceware.org, Mark Wielaard , binutils@sourceware.org, Ian Kelling Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 10/23/22 11:09, Frank Ch. Eigler via Libc-alpha wrote: > Hi - > >> [...] To be specific, gcc steering committee and glibc FSF stewards >> have announced the decision for their projects [...] > I may be missing something. All I've seen so far were some of the > leaders of some of the projects being joint signatories to a letter on > overseers@. As far as I'm aware, that is not how any of these > projects make or announce **project decisions** with/to their > respective constituencies. Right.  It's a general statement of support from a variety of leaders but I wouldn't consider it authoritative from any project. For GCC the decision would be made by the overseers and relayed to the overseers as an official statement for the GCC project. That would happen after a vote by the steering committee members based on already established voting procedures. > > >> I am not aware of any opposition from maintainers of libabigail or >> cygwin or any other active sourceware based project over moving >> either, but I haven't had any links to those projects, so I may be >> uninformed. > Indeed. The onus is obviously on the shoulders of the proponents of > this proposal to convince each sourceware guest project to consent to > move. If you wish to frame any dissent as "blocking full migration", > then I'd say the job of convincing everyone just has not been up to > par. Perhaps it was the wrong goal all along. Also agreed.  And I fully support needing a statement from project leadership for each project wishing to move.    That is reasonable and I wish we'd been clearer about that. In simplest terms, overseers need  to be a neutral party here. In cases where overseers have leadership roles on particular projects, then they will have to wear multiple hats, but it's not really complicated.  Each project makes a decision, by whatever means project leadership has in place to make decisions. overseers then honors those requests to stay or go.  It's a pretty simple separation of responsibilities.  It need not be contentious in any way shape or form. Jeff