From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id AGL6KS71bWUYShcAWB0awg (envelope-from ) for ; Mon, 04 Dec 2023 10:50:06 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=b3eh53Dl; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A20851E0C0; Mon, 4 Dec 2023 10:50:06 -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 7E7381E00F for ; Mon, 4 Dec 2023 10:50:04 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E1411385734E for ; Mon, 4 Dec 2023 15:50:03 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 5FC0D3858D28 for ; Mon, 4 Dec 2023 15:49:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5FC0D3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5FC0D3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701704993; cv=none; b=DaUOTtE2GC38R33pok0dHuj6T++HCW+1sBF5E290g5wVGRzO5JrxaclYi9QPw3uuOvF2TNSoB41K4N5Zbz5QDzBHi7FXTjlbZ7ntO8ycvLForN3VHJY8BoHUSM20pAtu2uqykXz7FUMsfzj6SWcI8qaCBAc/zo+qgeWta7Kex+U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701704993; c=relaxed/simple; bh=F8bg67XbSp/xsaTpMtOPOiI973eac7iNw+8oXC7Kv4Y=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=qqpHSkt0m1FPGeu4yfce+dV40X4DTzhNCU3UUrx6iQCgPKdIpnjtRtbLVyt1fvVo2Qyvj5ExI2Lu5pjG+M0Yo4X+t2zaYv4jsmfzED9B14hip8ut9x6XlubFbf1T8mUZN3uE+/RT1n9DTa6MuITzWIs3QjEOeQh5bjuKOqzINsQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701704992; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ia802pi/+61lgEk1dw0gn7dgtq0bctZw9zenhTHgOFM=; b=b3eh53DldtcPUsqt04gV35OgJLhGnk2ZADmrSU6arBSLO2EuURfFUInMoYCviI2hgJwZfH ikLWFSslpqpctN0yFyO5fQgMjH0Ty7QIeGTezq1LMTC0xXxjWDnLRk8JUNSdTQtyl1GigF odS+p5IFejoYS+H/1DysqKhTRML206A= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-317-olf_xyfyNJiFfgt-BOxW3w-1; Mon, 04 Dec 2023 10:49:50 -0500 X-MC-Unique: olf_xyfyNJiFfgt-BOxW3w-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-40c032abab6so18495325e9.3 for ; Mon, 04 Dec 2023 07:49:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701704989; x=1702309789; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Ia802pi/+61lgEk1dw0gn7dgtq0bctZw9zenhTHgOFM=; b=RKNar8KrOJVWDT4iv2XmcKebijtzWqziVuquTMP5kVknRJZZBnPoYT+OAFi/mToLHW F6xlrtIQD9BmjRmgLFYs2eK5MS7sl2FdYByPslNSdXhdy2rGP7urmMKJ8TPWuZZWhAzF eR6FjfkBpv+Lyz/1FsZqAhIDTVPqOZrWyz8lugUOJORfZI+pMxdAaRYuSG4yY5YxQdWk cwvdfIXJenJ68ehihMQWqZeReO5qE+YYlsVSI0JqajvMHhgt24kLNsWAZ9UXiqFwacas zgxnIqkmxotJcdAJ4CyuiPpp3eqW+XePkezl2eiTXR07lGrV5RTFRbFs8mkMUT+pPTJ6 7qMA== X-Gm-Message-State: AOJu0YyykR8580XIG0VGuvxiI8GW1oHJp0CCW0mK871uLwKIgtpvxoEk vPH+ZxutjTMt8AAL3uAP5I8/WggPGt8LNgs3TRs0s4tpIpKUZgjzd7nX4KD0umujZwCT3yJ5c8X 7cnpJOVAP60W+oYSFtPnwh6B1Hvx9sw== X-Received: by 2002:a05:600c:246:b0:40c:503:9bf0 with SMTP id 6-20020a05600c024600b0040c05039bf0mr1520196wmj.173.1701704989639; Mon, 04 Dec 2023 07:49:49 -0800 (PST) X-Google-Smtp-Source: AGHT+IEtJQP7w59+x4ilF4mFmQxQdg1Y3He/OhyGtDUQNkeYWOWbT6hdyAwbQ/PGYh5L/r8lVhIgeQ== X-Received: by 2002:a05:600c:246:b0:40c:503:9bf0 with SMTP id 6-20020a05600c024600b0040c05039bf0mr1520187wmj.173.1701704989300; Mon, 04 Dec 2023 07:49:49 -0800 (PST) Received: from localhost (105.226.159.143.dyn.plus.net. [143.159.226.105]) by smtp.gmail.com with ESMTPSA id o18-20020a05600c511200b004064e3b94afsm19043870wms.4.2023.12.04.07.49.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Dec 2023 07:49:48 -0800 (PST) From: Andrew Burgess To: Mike Frysinger Cc: gdb-patches@sourceware.org Subject: Re: Introducing a GDB Code Of Conduct In-Reply-To: References: <87edg7nsen.fsf@redhat.com> Date: Mon, 04 Dec 2023 15:49:47 +0000 Message-ID: <87leaage78.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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 Mike Frysinger writes: > 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. Mike, I agree that having a common policy would be great. But as Eli has already said, he strongly objects to both the GCC and binutils CoC. And if it comes to loosing Eli from the project or adopting a different CoC, then I choose the latter. I don't feel there is anything significantly different between what is proposed here and either of the other CoC. But I don't see any significant cost in having a different policy. Even if we did adopt the same policy as some other project, I'd still be proposing that we (GDB) should have our own CoC committee -- it's pretty important to me that this should be the community policing itself, not some outside group policing us. As such, we (GDB) might choose to handle/interpret some situation slightly differently to another project -- so simply having the same written words wouldn't necessarily mean things are handled exactly the same. Thanks, Andrew