Re: Any concrete plans after the GDB BoF?

[Luis Machado <luis.machado@arm.com>]

Hi Simon,

On 10/28/22 17:16, Simon Marchi wrote:
> 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.

I think those of us usually chatting on IRC are aware that you restarted it, so thanks for doing that.

With that said, John Baldwin exposed some valid points. I also find the Patchwork workflow and interface odd and hard
to work with. I can't simply pick up a random patch and easily review it like I did with Gerrit, for example. I need to go
out of my way to find it there, look for the mailing list entry etc.

I feel this goes a bit against enabling non-maintainers to do code reviews. The current workflow, though it works nicely
for some, is quite limited and very prone to letting patches be forgotten at the end of the list. There are better ways to
get this done these days.

The PING mechanism, for example, is a burden. It is more manual work that you need to remember to do. On the other hand, if patches are
archived in a good way in some system, it is just a matter of someone spotting it in a list and reviewing it.

For instance, someone may have 5 minutes to spare. This person might go and look for a smaller patch to review, make comments inline
and go off to do something else.

In summary, even though glibc uses patchworks, it might not be the case it is the best tool for the GDB community. We seem
to be short on reviewers (maintainers and non-maintainers). Enabling more non-maintainers to do reviews seems like a positive
move towards a more efficient development process upstream.

Some people admittedly don't like gerrit, but the tool has a lot of benefits, plus it integrates very nicely with Jenkins. And we need
to have continuous testing back for GDB development, otherwise we risk having targets getting silently broken. It is reasonable to say one
can't guarantee things won't break based solely on code reviews.

> 
>> 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.

Also, there are lots of different code styles out there. It is not unusual to have GDB contributors doing other work on
a project with different formatting standards. Having to remember formatting nits is not very pleasant nor efficient it seems.


> 
> Simon