From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ebvwMMk+tWqpPz0AWB0awg (envelope-from ) for ; Thu, 24 Sep 2026 11:16:25 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gotplt.org header.i=@gotplt.org header.a=rsa-sha256 header.s=dreamhost header.b=o13Wo7eo; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BE5FC1E06B; Thu, 24 Sep 2026 11:16:25 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B20651E01F for ; Thu, 24 Sep 2026 11:16:24 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5E8974BAE7CE for ; Thu, 24 Sep 2026 15:16:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5E8974BAE7CE Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gotplt.org header.i=@gotplt.org header.a=rsa-sha256 header.s=dreamhost header.b=o13Wo7eo Received: from iguana.tulip.relay.mailchannels.net (iguana.tulip.relay.mailchannels.net [23.83.218.253]) by sourceware.org (Postfix) with ESMTPS id 54D7F4BB58DD; Thu, 24 Sep 2026 15:15:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 54D7F4BB58DD Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 54D7F4BB58DD Authentication-Results: sourceware.org; arc=none smtp.remote-ip=23.83.218.253 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790262942; cv=none; b=QDnz+jUnfKMcvHxD2MgsKhkJS3CKeaKp/C6Yb/QukHyGtKmJ49xNvCFAzlrq98yP0ZRrVVAxvoWBN3G7i7WGKoLuObjBs8UxAzN5NUE3ScjYUtt5aOEgAtFfgI1DLRsGeeZcZ0Dux0LXVp+rnBxy1yORj37lyOOO6Im66hHRFEc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790262942; c=relaxed/simple; bh=76CrCpkXSYpqUQ5ZjHvS84+jQIk4NjI7nqqdGB1GZJ4=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=UJ/HfImWnqIAykq8vUZuBBx8JPN9jpVxj4oAqTq+TPYd9IEAAToATTW9jPABwlQ3WIt7aDBYc9HDuSOmxIdkxFUFlwoD0WgWMjpulN30LLVUfggzxlOQLHjFTTyfCyjPWfWY9iTlhdpC+PTUvIMnfkXv7hVuVXhOUDHpA6zcuRk= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gotplt.org header.i=@gotplt.org header.a=rsa-sha256 header.s=dreamhost header.b=o13Wo7eo DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 54D7F4BB58DD X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5925646169E; Thu, 24 Sep 2026 15:15:41 +0000 (UTC) Received: from pdx1-sub0-mail-a253.dreamhost.com (100-100-63-42.trex-nlb.outbound.svc.cluster.local [100.100.63.42]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 1090E462050; Thu, 24 Sep 2026 15:15:36 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Daffy-Well-Made: 0857b957319d50a1_1790262941228_2857393089 X-MC-Loop-Signature: 1790262941228:741723249 X-MC-Ingress-Time: 1790262941228 Received: from pdx1-sub0-mail-a253.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.100.63.42 (trex/8.0.2); Thu, 24 Sep 2026 15:15:41 +0000 Received: from [192.168.8.195] (unknown [38.74.41.78]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a253.dreamhost.com (Postfix) with ESMTPSA id 4hrHTM21B4zylQ; Thu, 24 Sep 2026 08:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1790262935; bh=Gl/+J5n9tdN1kJXvOv0xS7gfBE9zY2unUSqGKG8QNko=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=o13Wo7eoyVZm8SnfkSYRzJccH6tWrC9meO7cKr9VpScRhKqkegpW2ihyLtTw5x9iu IrelF5es61mk8Q2QgK+ZMwXz1is9Nr9wtKa0M+5X3gbeAr40LsIb+ZSE7jvZKEhzDF bCMbz8qjZvbdagJpRIb9FHiPumO1C07WR6Jve7rnEGG+nqm3Ua+RkCxufzO2ierdMX qGIO0O/yeTmQxgz1AZoBj4u5j9f2da0DDtQBzS7jub+mWitxExqf9i2ZanmGpItNT1 BcFk1H3qkXCIkcgdVZzhYdrUHPV1z4FpC7ZNOSHdai80r2OY8uXy02mSWhBdJfhN7+ oLAv6eO78gnog== Message-ID: <043b5970-6211-41cc-a6bd-2cbf017e5b64@gotplt.org> Date: Thu, 24 Sep 2026 11:15:24 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Meeting Minutes - Office Hours for CTI - 2026-09-18 To: Andrea Pinski , Joseph Myers Cc: Carlos O'Donell , gcc developers , glibc developers , gdb developers , binutils developers References: <0c071aeb-14f4-cd62-8fab-f3eb2659f77b@redhat.com> Content-Language: en-US From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 2026-09-22 15:02, Andrea Pinski wrote: >> The use of glibc in the list names is formally redundant, but we felt it >> was convenient for informal references to the lists in text, email client >> aliases, etc. to be able to talk about e.g. glibc-devel and have it >> unambiguous rather than just talking about devel@ which could refer to >> multiple projects. > > So there was no consensus on the community members except for the ones > who were at the meeting? There was a loose consensus among those present at the meeting (Carlos, myself and Joseph). I had leaned towards not having subdomains when Konstantin said that configuration would be more convenient to support vs subdomains, but aligned with Joseph's position when he explained it. > Ok. I think that it is wrong to have separate domains. The moving > part is a bad reason for having a seperate domain. If we have a > separate domain the redundant part is just broken and maybe better > names could come up with. Why is it broken? Could you suggest better names? I think ease/independence of movement is a great reason to have separate subdomains and more importantly, is more than just a personal preference. > Also why NOT use a forge for patches instead of pushing for mailing lists? That's not a CTI question, that's a community question. With my glibc contributor hat on, I don't think it's an either-or question. > Also why NOT just one email list? Why 6 mailing lists? > What is the need for glibc-stable? DJ already answered this; glibc-stable is actively used by downstream developers. I won't object if there's consensus towards folding it into libc-alpha, but that would mean dozens of additional (likely irrelevant for others) messages on the list. That said though, I do like the idea of the original patch and backports all living in the same list, ideally with a `References` tag linking them up since that would make processing them so much easier, especially for security fixes. As an aside, I had riffed on the idea in the past of a bot sending out [committed] emails to libc-alpha whenever there's a commit that did not land on the mailing list first. I ended up write a cron job for myself to track this, which isn't very useful anymore since we're not doing anything with that information. Maybe we could finally implement that *and* make the libc-stable messages entirely bot-driven so that contributors doing backports have one less step to do? > Maybe glibc-testresults should not be a mailing list but rather a > better way of collecting test results and displaying them? There's bunsen, but again, that's not an either-or question. We can always shut down the mailing list if we decide that it's not in use anymore. I don't think anybody has actually looked at that lately. Thanks, Sid