From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KC/cM9oibGXpABYAWB0awg (envelope-from ) for ; Sun, 03 Dec 2023 01:40:26 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=lIwbefaL; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C683A1E0C0; Sun, 3 Dec 2023 01:40:26 -0500 (EST) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 90E841E00F for ; Sun, 3 Dec 2023 01:40:24 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BDF9A3857BA1 for ; Sun, 3 Dec 2023 06:40:23 +0000 (GMT) Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id DB3523858C53 for ; Sun, 3 Dec 2023 06:40:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DB3523858C53 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DB3523858C53 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701585613; cv=none; b=U/huYU3M34SpN526KmBwxCwcquE8zq24WEY1KY/g9OrpuwTSZsrJ+blEZ8XCbIbMXE5aUjyUtLqOwPcElVakORxbYXyZ+GEKhuqlbaV6QSHzHN8krPuDs1umt/r0bITnRfpAEiqd7ZpcUJilVupan2haJRQkUfwA4epF8hxGJ9I= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701585613; c=relaxed/simple; bh=N7woM7nNBN/TfLAiAQvnb295qrRL5eBfVBu8yl9O6xU=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=BrvP1eQHdF7xlGQUjd4/FyjOrpG9iFMwYAK30JwxAse7lyS/R+6QZWWoRO+r/328FbNOa6H9581BDPSVDlmgqDBB7DSrYR1lnBrRRE+rf/6f00CWcTHxyhZHPW7DxAuGbL3vo0kYes6o85jy2fFwALJqTKW/6UM4gjDva1YyOXo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r9g9D-00026x-0r; Sun, 03 Dec 2023 01:40:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=UUhZYQgEBODSSdixAHGLKqln3T+01UpSIlaPHUvpxTE=; b=lIwbefaLeFjb GESBhe4SSJfGQxdzNff7pau3bNNJ1dQyLAiVc4DrQzfI68KUoU0Sjf5nI6rpvid816XLUlpUPb9xK noGX4iwEkiccGbeaPQaWK2FE9mfEy+QgmXWVrZ5eTJnzXTy3fDcSWKpHaZZTCYhK9loJQu7zrtt2W MSKTk08d5m11pFzM/cQbEYEEXZHbRsGFiPyBhGZGeD2IZhblKGovhA0vk1p2bY7A9QIR386ZhtsSX e0NNzdjhBT7aF6lBU1oNX5rp96nfU3575aoVQAvzzzuThOrjDnj+aU25R10s8n9bSJN0TeI8pvf60 7Kso8xuiL+U1xxP9+6x+ug==; Date: Sun, 03 Dec 2023 08:40:12 +0200 Message-Id: <83v89f7prn.fsf@gnu.org> From: Eli Zaretskii To: Mike Frysinger Cc: aburgess@redhat.com, gdb-patches@sourceware.org In-Reply-To: (message from Mike Frysinger on Sat, 2 Dec 2023 22:26:48 -0500) Subject: Re: Introducing a GDB Code Of Conduct References: <87edg7nsen.fsf@redhat.com> X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org > Date: Sat, 2 Dec 2023 22:26:48 -0500 > From: Mike Frysinger > Cc: gdb-patches@sourceware.org > > On 30 Nov 2023 15:59, Andrew Burgess wrote: > > Many GNU toolchain projects have adopted a Code of Conduct (CoC) > > recently, and I believe that GDB should do likewise. > > adopting a CoC sounds fine, but really seems like we should be using the > same one across them. there isn't anything in the content that screams > "this only makes sense for XXX project". can't we do this akin to how > we merge changes from "upstream" gcc tree ? > > yes, i know there are a few things inline like "here's the gdb e-mail", > but that should be fairly trivial to summarize at the beginning/end, or > ideally in a sep file altogether to make merging trivial. I would object to adopting the GCC CoC because it has some parts that I cannot live with, as a member of the GDB project and a global maintainer. That's why I wrote the GDB CoC in the first place, and the differences are not trivial, at least to me, and are not limited to the email addresses.