From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 21DAD3858D1E; Wed, 17 May 2023 02:28:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 21DAD3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.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 1pz6tu-0000uy-Aj; Tue, 16 May 2023 22:28:26 -0400 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=gVF9kPsCeaMgCqFc7op13lbUtetY6q+aPfP3J3+gGKE=; b=Czv5GbVloA+W m3rDObZV5x5BiNM0JVa9HMZtaV2oGeYevREgXQuN49rhQUQ/L31lVo6gQ+iK739/fWWKHaRs0MOif 5ZMf9T0S31HpI/9+d3VI/XoUMQyp9DyM29MlGfBbY+bRiAMqy7HMzEr5w2aS5JUcxckYP7l05V9+v 0YwHLvEQoTmk8i2FcQw8uOdyg7w8PMolbXaq3/FwVpMA41+ADHsdmVlangEWqFGZzWfGHSMh4Anvz iKT8Uuae435+xUMCth73nsIcCq7IkoApW2ekRSOui2cmD6qwCNqMD7KBYqoe47r7fQQdOnD/62fAG /CmqZ7tA0+WgGa1TiHhCJA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pz6tr-0003Q2-0n; Tue, 16 May 2023 22:28:23 -0400 Date: Wed, 17 May 2023 05:28:32 +0300 Message-Id: <831qjfzo6n.fsf@gnu.org> From: Eli Zaretskii To: Simon Marchi Cc: blarsen@redhat.com, gdb-patches@sourceware.org, gdb@sourceware.org In-Reply-To: <83728fde-a0e8-026b-d4d1-89975ff5ca28@simark.ca> (message from Simon Marchi on Tue, 16 May 2023 15:40:38 -0400) Subject: Re: [PATCH 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS References: <20230516143826.3431583-1-blarsen@redhat.com> <20230516143826.3431583-2-blarsen@redhat.com> <83pm70z2hr.fsf@gnu.org> <83cz30yxox.fsf@gnu.org> <83728fde-a0e8-026b-d4d1-89975ff5ca28@simark.ca> X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Date: Tue, 16 May 2023 15:40:38 -0400 > Cc: gdb-patches@sourceware.org, gdb@sourceware.org > From: Simon Marchi > > > I don't think I'm in a position to put forward suggestions, since I'm > > not sure I have a good understanding of the process. I only use > > Approved-By when I can approve the entire patch, not just parts of it. > > But maybe I'm wrong in that. > > If this happens, I think it's fine to say "the documentation parts are > approved" and following with your Approved-By. If you want to be > extra-clear, add "but the rest needs to be approved by someone else". > The patch will end up with multiple Approved-Bys. I'd like to hear from more maintainers that this is how they see that tag. My fear is that someone mechanically scans the discussion thread for the tags, in which case human-readable qualifications will go unnoticed. All in all, I feel that this aspect of our process is not well defined.