From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id nxeqL0zcY2QqBwwAWB0awg (envelope-from ) for ; Tue, 16 May 2023 15:41:00 -0400 Received: by simark.ca (Postfix, from userid 112) id B380F1E11E; Tue, 16 May 2023 15:41:00 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=nOtTGgHv; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from 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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5888B1E111 for ; Tue, 16 May 2023 15:41:00 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B64A9385B518 for ; Tue, 16 May 2023 19:40:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B64A9385B518 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1684266059; bh=oyzIVvpxER+T63aUQoYYsJ9Oyi4LRhZooEH/JzWOujE=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=nOtTGgHvrQvvEoWnMsoRSGmt7lcqBDx/0M+PJHsfh/K4ftO9pO3KnDHffePbzTC3y uSDyvoJ7JwwflxUv4veVC//QzpwtO5tTnOAnSnDybE9E2FwO1i4szSfhSXah6sWDfV j6kPXh/icgQXbwy1S+IIf8LF8CdESuihvJHRk+Bo= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 91EBE385843A; Tue, 16 May 2023 19:40:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 91EBE385843A Received: from [10.0.0.170] (unknown [167.248.160.41]) (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) by simark.ca (Postfix) with ESMTPSA id B60A01E111; Tue, 16 May 2023 15:40:38 -0400 (EDT) Message-ID: <83728fde-a0e8-026b-d4d1-89975ff5ca28@simark.ca> Date: Tue, 16 May 2023 15:40:38 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS To: Eli Zaretskii , Bruno Larsen Cc: gdb-patches@sourceware.org, gdb@sourceware.org References: <20230516143826.3431583-1-blarsen@redhat.com> <20230516143826.3431583-2-blarsen@redhat.com> <83pm70z2hr.fsf@gnu.org> <83cz30yxox.fsf@gnu.org> Content-Language: fr In-Reply-To: <83cz30yxox.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 5/16/23 13:48, Eli Zaretskii via Gdb-patches wrote: >> Date: Tue, 16 May 2023 18:41:55 +0200 >> Cc: gdb-patches@sourceware.org, gdb@sourceware.org >> From: Bruno Larsen >> >> On 16/05/2023 18:04, Eli Zaretskii wrote: >>>> + Used when a contributor has looked at code and agrees with the changes, >>>> + but either does not have the authority or doesn't feel comfortable >>>> + approving the patch (usually due to unfamiliarity with a certain >>>> + part of the code). >>> Reviewed-by is used by responsible maintainers as well. >> I think I need clearer wording then. > > I think "both contributors and maintainers" is good enough. > >>> I think the above list is incomplete, because there appears to be no >>> "git trailer" (why do we have to call it "git" trailer, btw? will >>> that change if we ever switch to a different VCS?) for the situation >>> where the responsible maintainer does approve some part of the patch, >>> but not all of it (e.g., because the other parts are not in the >>> expertise domain of that maintainer). I thought Reviewed-by is such a >>> trailer, but based on the above I'm beginning to think I was confused. >>> >> I wrote the proposal based on how I think the use of trailers works on >> the QEMU project (I wasn't in it long enough to be sure that I am >> correct, though). My thinking was that you'd send something like >> "documentation changes are approved, but someone needs to look at the >> code, Approved-By ..." or something similar. That said, I just >> remembered that they also use Ack-By in those situations and the >> maintainer of the subsystem most affected by a change is the only one to >> approve the patch, and other relevant maintainers use Ack-By (they have >> a very different development workflow, with each subsystem maintainer >> having their own tree and them only being merged into the master tree >> periodically). I'm pretty open to suggestions, if you think using >> Acked-By or some other trailer is better. That is the reason I'm doing >> this :-) > > 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. Speaking of Acked-By, I felt the need to use it recently, where I just read the commit message, agreed with it, but didn't have time to review the code itself. I wanted to show that I agreed with the intent of the patch. I think that's what Acked-By is for. I think we could add it to that list. Simon