From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.cs.ucla.edu (mail.cs.ucla.edu [131.179.128.66]) by sourceware.org (Postfix) with ESMTPS id 06E543858D20 for ; Fri, 1 Sep 2023 14:55:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 06E543858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 46DA83C011BDF; Fri, 1 Sep 2023 07:54:59 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id G7yR4lgA8Upy; Fri, 1 Sep 2023 07:54:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 9FD4C3C011BE0; Fri, 1 Sep 2023 07:54:58 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 9FD4C3C011BE0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1693580098; bh=+T972ZzI9YIiQNiDjmMGfHgXz0d5Wu6wk2qW+qmx93E=; h=Message-ID:Date:MIME-Version:To:From; b=Sh8pGGibfLlQLhKp4eeB1VMPEtJl31nRxLahW2tvHhn/vPIu1j0BqmWg7TPA0tiPP LIbBFO5Pu3QxieMoy3TU/haKNVbxNZj+ANvitTQvVVO2Sc6lPHP4jUDkO/+nip8Za3 Lb4JiuVkz23oigOC17rAwmjO6V1KUPT6MRrMDk5kMogFPQhisMWGGt5+3m0PXC+Fai uIKDUeUfpF4yFPph7KCrmXIZ00LlRuOEecIcn8NLCRFuVWkIc9FpFYJziVkN8pd2Gz UfVBfR8mlCodfYdcRe3KM2NTjjRSpKUBm6xGA4eJcnV2k2sVXzZT1fQuuWNMKtrtCk s6oe2piwuV7FA== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Tn-EL6Ygdb2l; Fri, 1 Sep 2023 07:54:58 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 5D5F63C011BDF; Fri, 1 Sep 2023 07:54:58 -0700 (PDT) Message-ID: <89eeebda-4f12-e819-4a8d-c0aaac50a3c9@cs.ucla.edu> Date: Fri, 1 Sep 2023 07:54:58 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US To: Siddhesh Poyarekar , Sam James , Mark Wielaard Cc: Jakub Jelinek , libc-alpha@sourceware.org, Andreas Schwab , Joseph Myers , Maxim Kuvyrkov , Carlos O'Donell References: <15af1715-3530-7c29-7595-5abe48c18e8b@cs.ucla.edu> <87ledqe8ej.fsf@gentoo.org> <43743bb5-e79e-f915-9528-4b3556de1c5c@gotplt.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: [Action Required] glibc decision to use CTI services. In-Reply-To: <43743bb5-e79e-f915-9528-4b3556de1c5c@gotplt.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-09-01 05:30, Siddhesh Poyarekar wrote: > It is the Technical Advisory Committee that decides on the=20 > infrastructure tech and that is comprised completely of members from th= e=20 > GNU toolchain community.=C2=A0 We will make sure that glibc services ar= e=20 > implemented using Free software. This sounds good, but I don't see the Linux Foundation agreeing to it in=20 the URLs Carlos mentioned at the start of this thread (see below). What=20 I see are statements[1][2] from the GNU Toolchain Infrastructure project=20 that GTI has "requested" that only free software be used. This is not=20 the same thing. It'd be helpful to have a statement from the Linux Foundation that they=20 agree to use only free software to support glibc, and that GTI's=20 Technical Advisory Committee is empowered to inspect the Core Toolchain=20 Infrastructure used for glibc, so that the GTI TAC can verify that only=20 free software is used. This shouldn't be that much to ask for. And I would think that the Linux=20 Foundation would welcome such an agreement, not only because the Linux=20 Foundation wants to support free software, but because it wants its=20 infrastructure to be open and checkable and usable by others. > it's not about the overseers, who have indeed been prompt in handling r= equests and providing support for existing infrastructure. It's about doi= ng things like service isolation, future enhancements/scaling and dedicat= ed devops It would indeed be nice to have things like that. Here are the URLs from Carlos's earlier email. > [1] https://sourceware.org/pipermail/overseers/2022q3/018896.html > [2] https://sourceware.org/pipermail/overseers/2022q4/018981.html > [3] https://lore.kernel.org/gti-tac/804cee43-a120-3acf-a302-b1640f2285a= 9@redhat.com/ > [4] https://lore.kernel.org/cti-tac/47d5d7a0-60ab-b400-2f75-880fdaae073= 8@redhat.com/T/#u > [5] https://sourceware.org/pipermail/libc-alpha/2023-August/150610.html > [6] https://sourceware.org/pipermail/libc-alpha/2023-July/150071.html