Any concrete plans after the GDB BoF?

Mark Wielaard
Sun Jan 1 22:02:50 GMT 2023


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:

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 ''
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
to match to diff to the patch in patchwork.

It is also possible starting from the patchwork side using DJs CI
framework 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.



More information about the Gdb mailing list