From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id eKrFM34AXGP6mxEAWB0awg (envelope-from ) for ; Fri, 28 Oct 2022 12:17:02 -0400 Received: by simark.ca (Postfix, from userid 112) id C0D801E11E; Fri, 28 Oct 2022 12:17:02 -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=VcaAVZUc; 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=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.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 690321E0CB for ; Fri, 28 Oct 2022 12:17:02 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 34DB33851179 for ; Fri, 28 Oct 2022 16:17:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 34DB33851179 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1666973821; bh=8sHtL/X13xoPGr44dvo2TfdFQ7mNExZoLK3q6VZ7UnY=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=VcaAVZUc0XM9kEWtHnDnVsXMpyK8n46wLOvBu7WRoXMxRlPd+YC1AIrrfKRGWNIND FLZyzF63Y+nAxZBvCtjrgO4uccFy/UAXDG41KSNCae1KX44rN8US8CS3WbuUMexfXD OrIw7OKidaBsuOmTF4G7YjQ1YAUduSsrEMTrW+gw= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 933F13857838 for ; Fri, 28 Oct 2022 16:16:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 933F13857838 Received: from [10.0.235.143] (modemcable075.250-20-96.mc.videotron.ca [96.20.250.75]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 2C7D01E0CB; Fri, 28 Oct 2022 12:16:35 -0400 (EDT) Message-ID: Date: Fri, 28 Oct 2022 12:16:34 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: Any concrete plans after the GDB BoF? Content-Language: fr To: Luis Machado , "gdb@sourceware.org" References: <83485199-965e-7ff5-1dc8-d027b74b56f7@arm.com> In-Reply-To: <83485199-965e-7ff5-1dc8-d027b74b56f7@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Cc: Mark Wielaard Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 2022-10-27 06 h 47, Luis Machado via Gdb wrote: > Hi, > > Having suggested a few topics for the GDB BoF (I noticed they were discussed, to some extent), are there > any concrete plans from the GDB global maintainers (leadership? I don't know how to call it) to address > some of those concerns? > > Simon was kind enough to cleanup the patchworks instance, though that is not yet fully integrated into > something we can easily use to do tests/CI. I see the number of unreviewed patches is growing again. > > For example, it is not easy to pick a patch to review. You need to locate the entry in your inbox so you > can reply to it. I do not know of a way to trigger CI tests from Patchwork, that would perhaps be a question for Mark (added in CC). On a personal note, coming back from the Cauldron, I set myself a goal to do more reviews as part of my daily work. I'm trying to do around 1 hour a day of upstream reviews, and to choose what to review, I use patchwork, sorting patches by oldest date. I check if the patch I'm looking at has already been reviewed, merged, or superseded by a new version, and if so I update its status. Rinse and repeat until I find a patch that needs reviewing. Otherwise, just looking at my inbox's gdb-patches folder with thousands of unread messages, I don't know what to start with. Just by myself, I certainly won't get through the whole list of patches pending review, but I think it is a somewhat fair algorithm. So in that regard, patchwork is useful for me. I wanted to send an announcement on the list to say "hey, patchwork has been cleaned, let's use it!", but I have been procrastinating since I came back. > On formatting, have we considered the benefit of using clang-format for GDB, therefore potentially saving lots of time > in reviews not having to worry about formatting? This often comes up, I am all for it. We need someone to write up a proposal of how this would work (a bit like Bruno did for the attribution tags). I might get to it, but I don't promise anything. Simon