From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 8B7593858D1E for ; Sun, 1 Jan 2023 22:02:51 +0000 (GMT) Received: by gnu.wildebeest.org (Postfix, from userid 1000) id 7BB3B300072D; Sun, 1 Jan 2023 23:02:50 +0100 (CET) Date: Sun, 1 Jan 2023 23:02:50 +0100 From: Mark Wielaard To: Luis Machado Cc: Simon Marchi , "gdb@sourceware.org" , John Baldwin Subject: Re: Any concrete plans after the GDB BoF? Message-ID: <20230101220250.GA11041@gnu.wildebeest.org> References: <83485199-965e-7ff5-1dc8-d027b74b56f7@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-3032.2 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, On Mon, Oct 31, 2022 at 09:28:08AM +0000, Luis Machado wrote: > On 10/28/22 17:16, Simon Marchi wrote: > >On 2022-10-27 06 h 47, Luis Machado via Gdb wrote: > > >>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 use git-pw for that: https://patchwork.readthedocs.io/projects/git-pw/ Once installed (pip install --user git-pw works if your distro doesn't package it) you can configure inside your binutils-gdb git checkout: git config pw.server 'https://patchwork.sourceware.org/api/1.2/' git config pw.project 'gdb' Then you can use git pw patch list to get a list of patches and git pw patch download --mbox 62243 to fetch a particular patch as sent to the mailinglist. This includes the original from, to, cc headers so you can just reply to it (after importing the mbox into your mailer, I use mutt -f). git-pw also makes it easy to git am the patch (series). If you have a patchwork account for gdb you can also generate an API token to update the state of patches. > >I do not know of a way to trigger CI tests from Patchwork, that would > >perhaps be a question for Mark (added in CC). We can do it from two sides. As Frank suggested we can use the (try) buildbots. It is easy to apply patchwork patches with git-pw and then push them git push origin users/$USERID/try-TOPIC If we make the buildbot a patchwork user then we can make builder update the test flags in patchwork. Similarly we can make the buildbot notice a patch being committed and update the state of the patch in patchwork to committed. Both just need to use the patchwork hasher.py to match to diff to the patch in patchwork. It is also possible starting from the patchwork side using DJs CI framework https://sourceware.org/glibc/wiki/CICDDesign When that gets authentication of users/patches we could use that to trigger the buildbots and make patchwork itself submit a try build. > >>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. > > I can do it. I know some of us tried it already. Tom Tromey seems to > have done it as well. > > I think this is another step towards getting the contribution burden > off of contributors. Formatting should not be something one needs to > spend time with. One space x two spaces, 80 columns x 100 columns > are certainly not as important as code that does what needs to be > done and improves GDB overall. I believe the python black formatter is pretty useful and now integrated into the buildbot so that any commit that fails the format checker is flagged. We can do the same for clang-format once there is agreement on the specific settings. Cheers, Mark