Any concrete plans after the GDB BoF?

Any concrete plans after the GDB BoF?

[Luis Machado]

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.

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?

Any other topics?

Thanks!
Luis

Re: Any concrete plans after the GDB BoF?

[Simon Marchi]

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

Re: Any concrete plans after the GDB BoF?

[John Baldwin]

On 10/28/22 9:16 AM, Simon Marchi via Gdb 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.

Interesting.  Does the date factor in pings?  That is, if you ping a series
does it move earlier in the list or does it keep its original date?

Actually, I guess not all pings work.  I have a series I posted back on
July 7th and have pinged a few times since that doesn't show up in patchworks.
(And I only confirmed that by finding some other closed patch with my username
so I could do a query by username.)  Maybe because the pings were all replies
that had 'Re:' prefixes in the subject?  If we need to format pings in a
certain way, that would be good to know.  Alternatively, if old patch series
just need to be re-posted that would also be good to know.

The web UI for patchworks also seems a bit buggy.  Not sure who to provide
feedback to?  Trying to do a text search on a series name (e.g. putting a
keyword in the series name field) just ignores the text field and returns all
patches.  Also, if you click on a different field like Submitter and then try
to go to another page, it resets the sort order on the second page to sort by
Date.  If you then change the sorting key on the second page, it reverts back
to the first page with the new key.  I haven't tried manually constructing the
parameters in the URL to get to the second page with a new key.

-- 
John Baldwin

Re: Any concrete plans after the GDB BoF?

[Simon Marchi]

On 2022-10-28 12 h 51, John Baldwin wrote:
> On 10/28/22 9:16 AM, Simon Marchi via Gdb 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.
> 
> Interesting.  Does the date factor in pings?  That is, if you ping a series
> does it move earlier in the list or does it keep its original date?
> 
> Actually, I guess not all pings work.  I have a series I posted back on
> July 7th and have pinged a few times since that doesn't show up in patchworks.
> (And I only confirmed that by finding some other closed patch with my username
> so I could do a query by username.)  Maybe because the pings were all replies
> that had 'Re:' prefixes in the subject?  If we need to format pings in a
> certain way, that would be good to know.  Alternatively, if old patch series
> just need to be re-posted that would also be good to know.
> 
> The web UI for patchworks also seems a bit buggy.  Not sure who to provide
> feedback to?  Trying to do a text search on a series name (e.g. putting a
> keyword in the series name field) just ignores the text field and returns all
> patches.  Also, if you click on a different field like Submitter and then try
> to go to another page, it resets the sort order on the second page to sort by
> Date.  If you then change the sorting key on the second page, it reverts back
> to the first page with the new key.  I haven't tried manually constructing the
> parameters in the URL to get to the second page with a new key.

Indeed, patches that were submitted previously don't appear.

Simon

Re: Any concrete plans after the GDB BoF?

[Luis Machado]

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

Re: Any concrete plans after the GDB BoF?

[Simon Marchi]

On 10/31/22 05:28, Luis Machado wrote:
> 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.

I agree with all you said.  However, there wasn't a consensus when we
tried to move to Gerrit a few years ago, not sure why there would be one
now.

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

I agree with all you said.  There is always some resistance related to
how clang-format handles this or that case.  In my opinion, that's minor
compared to the benefit of using it.  My opinion would be: make the
clang-format config that is closest to our style today, make a big
re-format, and carry on.  If there are some things that clang-format
doesn't do as we like, then we have an incentive to push to fix it.

I say "clang-format" here because it is the only tool I know of that
makes a reasonably good job at formatting C++ code.  If you know others,
please mention them.

Simon

Re: Any concrete plans after the GDB BoF?

[Joel Brobecker]

> I agree with all you said.  There is always some resistance related to
> how clang-format handles this or that case.  In my opinion, that's minor
> compared to the benefit of using it.  My opinion would be: make the
> clang-format config that is closest to our style today, make a big
> re-format, and carry on.

I agree with that. As long as the formatting is consistent, it might
take a little getting used to, but I think we'll be happier if we don't
have to spend time worrying about code formatting.

The one small obstacle, perhaps, might be if different versions of
the tool format things differently. In that case, we might have to
clearly state which version we expect the code to be formatted with.
I am thinking of the kind of issues we get with the configury which
is generated by the auto tools, which is so dependent on the version
that even the distro-provided versions introduce spurious differences
sometimes, as a result of which I have built my own set of vanilla
autotools. If clang-format is tricky to build, we may have issues
in that respect...

-- 
Joel

Re: Any concrete plans after the GDB BoF?

[Simon Marchi]

On 10/31/22 09:37, Joel Brobecker via Gdb wrote:
>> I agree with all you said.  There is always some resistance related to
>> how clang-format handles this or that case.  In my opinion, that's minor
>> compared to the benefit of using it.  My opinion would be: make the
>> clang-format config that is closest to our style today, make a big
>> re-format, and carry on.
> 
> I agree with that. As long as the formatting is consistent, it might
> take a little getting used to, but I think we'll be happier if we don't
> have to spend time worrying about code formatting.
> 
> The one small obstacle, perhaps, might be if different versions of
> the tool format things differently. In that case, we might have to
> clearly state which version we expect the code to be formatted with.
> I am thinking of the kind of issues we get with the configury which
> is generated by the auto tools, which is so dependent on the version
> that even the distro-provided versions introduce spurious differences
> sometimes, as a result of which I have built my own set of vanilla
> autotools. If clang-format is tricky to build, we may have issues
> in that respect...

I would suggest mandating one version, and for that version to
continuously be the latest stable version of clang-format, like we do
for Black.  When a new version comes out, we don't have to wonder if /
when we move the next version.  Someone just pushes a patch re-formating
the code to the next version, if there are some differences.  It keeps
the overhead to a minimum.

So far I have never seen problems related to distro-specific patches, as
we have seen with autoconf.

For Debian/Ubuntu, it's easy to get the latest stable version through
apt.llvm.org.  I don't really know about other distros.  In any case,
it's easy to build and not long (not long like building the whole
llvm/clang):

$ git clone --depth 1 https://github.com/llvm/llvm-project.git --branch release/15.x
$ mkdir -p llvm-project/build
$ cd llvm-project/build
$ cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles" ../llvm -DCMAKE_INSTALL_PREFIX=/tmp/llvm
$ make -j 4 clang-format
$ make install-clang-format
$ /tmp/llvm/bin/clang-format --version
clang-format version 15.0.4 (https://github.com/llvm/llvm-project.git 08bd84e8a6358eb412fcef279f8875e2d69a3374)

Simon

Re: Any concrete plans after the GDB BoF?

[Joel Brobecker]

> I would suggest mandating one version, and for that version to
> continuously be the latest stable version of clang-format, like we do
> for Black.  When a new version comes out, we don't have to wonder if /
> when we move the next version.  Someone just pushes a patch re-formating
> the code to the next version, if there are some differences.  It keeps
> the overhead to a minimum.
> 
> So far I have never seen problems related to distro-specific patches, as
> we have seen with autoconf.
> 
> For Debian/Ubuntu, it's easy to get the latest stable version through
> apt.llvm.org.  I don't really know about other distros.  In any case,
> it's easy to build and not long (not long like building the whole
> llvm/clang):
> 
> $ git clone --depth 1 https://github.com/llvm/llvm-project.git --branch release/15.x
> $ mkdir -p llvm-project/build
> $ cd llvm-project/build
> $ cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles" ../llvm -DCMAKE_INSTALL_PREFIX=/tmp/llvm
> $ make -j 4 clang-format
> $ make install-clang-format
> $ /tmp/llvm/bin/clang-format --version
> clang-format version 15.0.4 (https://github.com/llvm/llvm-project.git 08bd84e8a6358eb412fcef279f8875e2d69a3374)

Thanks for sharing, Simon. This makes the option of using this tool
very attractive.

-- 
Joel

Re: Any concrete plans after the GDB BoF?

[Frank Ch. Eigler]

Luis Machado via Gdb <gdb@sourceware.org> writes:

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

Note that gdb maintainers can push hypothetical patches to personal
try-branches on sourceware.org ("git push origin users/$USERID/try-TOPIC"),
and the local buildbot environment will build that branch on a variety
of hosts, report build failures, and store test results in bunsen.  This
is not integrated into patchwork, but is easily triggered by anyone with
commit privileges.

- FChE

Re: Any concrete plans after the GDB BoF?

[Luis Machado]

On 10/31/22 09:28, Luis Machado wrote:
> 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.

FTR, this is still on my TODO list. Hopefully I can get some spare cycles to submit something in the coming weeks.

Re: Any concrete plans after the GDB BoF?

[Mark Wielaard]

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

Re: Any concrete plans after the GDB BoF?

[Tom Tromey]

>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:

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

Mark> I use git-pw for that:
Mark> https://patchwork.readthedocs.io/projects/git-pw/

Just to be clear -- I think if people want to use git-pw, they should,
and shouldn't wait for some official blessing.

thanks,
Tom

Re: Any concrete plans after the GDB BoF?

[Tom Tromey]

Mark> I use git-pw for that:
Mark> https://patchwork.readthedocs.io/projects/git-pw/

Tom> Just to be clear -- I think if people want to use git-pw, they should,
Tom> and shouldn't wait for some official blessing.

I gave it a look today.  There were 8 pages of patches, but nearly all
of them have been checked in.  I went through and cleaned out a few
pages, but TBH this is pretty boring, not to mention error-prone.

Tom

Re: Any concrete plans after the GDB BoF?

[Lancelot SIX]

On Fri, Jan 20, 2023 at 01:30:00PM -0700, Tom Tromey wrote:
> Mark> I use git-pw for that:
> Mark> https://patchwork.readthedocs.io/projects/git-pw/
> 
> Tom> Just to be clear -- I think if people want to use git-pw, they should,
> Tom> and shouldn't wait for some official blessing.
> 
> I gave it a look today.  There were 8 pages of patches, but nearly all
> of them have been checked in.  I went through and cleaned out a few
> pages, but TBH this is pretty boring, not to mention error-prone.
> 
> Tom

Hi,

I usually try to run a script doing this automatically.  However, it can
only detect when a checked-in patch exactly matches what have been sent
to the ML.  So the situations where we have "OK to merge with this
detail fixed" will not be caught by the script.

Also, I wish patchwork could automatically close a patches/series when a new
revision is sent to the ML. This is another class of patches which
remain on patchwork when they should probably not.  I did try to close
those manually in the past, but got overwhelmed, so I do not do that
anymore.

That being said, I still use git-pw to fetch and apply patch and series.
This is really convenient when I am not working on the host where I have
my mail client.

Lancelot.

Re: Any concrete plans after the GDB BoF?

[Tom Tromey]

>>>>> "Lancelot" == Lancelot SIX <lsix@lancelotsix.com> writes:

Lancelot> I usually try to run a script doing this automatically.  However, it can
Lancelot> only detect when a checked-in patch exactly matches what have been sent
Lancelot> to the ML.  So the situations where we have "OK to merge with this
Lancelot> detail fixed" will not be caught by the script.

Yeah.  For gdb, if we plan to use this, I think we should require a
gerrit-like Change-Id so that the process can be made more reliable.

Unfortunately this requires hacking on patchworks which I tend to doubt
is going to happen.

Lancelot> Also, I wish patchwork could automatically close a patches/series when a new
Lancelot> revision is sent to the ML. This is another class of patches which
Lancelot> remain on patchwork when they should probably not.  I did try to close
Lancelot> those manually in the past, but got overwhelmed, so I do not do that
Lancelot> anymore.

Me too.  Maybe the Change-Id thing could also be used to automate this.
In this case it's fine by me if the occasional patch slips past -- for
instance if someone drops a patch from a series, and the dropped patch
still shows up, I guess that is rare enough that I would be ok handling
it manually.

Lancelot> That being said, I still use git-pw to fetch and apply patch and series.
Lancelot> This is really convenient when I am not working on the host where I have
Lancelot> my mail client.

Have you tried b4 instead?  I haven't yet but it seems like the same
thing but without needing patchwork, just public inbox.

https://b4.docs.kernel.org/en/latest/index.html

Tom

Re: Any concrete plans after the GDB BoF?

[Lancelot SIX]

> Lancelot> That being said, I still use git-pw to fetch and apply patch and series.
> Lancelot> This is really convenient when I am not working on the host where I have
> Lancelot> my mail client.
> 
> Have you tried b4 instead?  I haven't yet but it seems like the same
> thing but without needing patchwork, just public inbox.
> 
> https://b4.docs.kernel.org/en/latest/index.html

I haven't yet either.  For now git-pw seems to allow me to do what I am
trying to achieve.  I'll still try to have a closer look at b4 to check
if it can provide a better experience.

Lancelot.

Re: Any concrete plans after the GDB BoF?

[Mark Wielaard]

Hi,

On Mon, Jan 30, 2023 at 05:43:18PM +0000, Lancelot SIX wrote:
> > Lancelot> That being said, I still use git-pw to fetch and apply patch and series.
> > Lancelot> This is really convenient when I am not working on the host where I have
> > Lancelot> my mail client.
> > 
> > Have you tried b4 instead?  I haven't yet but it seems like the same
> > thing but without needing patchwork, just public inbox.
> > 
> > https://b4.docs.kernel.org/en/latest/index.html
> 
> I haven't yet either.  For now git-pw seems to allow me to do what I am
> trying to achieve.  I'll still try to have a closer look at b4 to check
> if it can provide a better experience.

b4 acts a little different from git-pw. It uses Message-IDs to fetch
patches (and/or a whole thread as mbox). So it helps if your mta
displays those prominently. If you use emacs you might be interested
in piem: https://git.kyleam.com/piem/about/

For gdb-patches you want to add the following to your .git/config:

[b4]
    midmask = https://inbox.sourceware.org/gdb-patches/%s
    linkmask = https://inbox.sourceware.org.org/gdb-patches/%s

There is a command line example in this presentation:
https://gnu.wildebeest.org/~mark/fsf-sourceware/presentation.html#slide14

The latest b4 can also interact with patchwork, but I haven't tried
that out yet. The new settings are described at:
https://b4.docs.kernel.org/en/latest/config.html#patchwork-integration-settings

Cheers,

Mark

Re: Any concrete plans after the GDB BoF?

[Tom Tromey]

>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:

Mark> For gdb-patches you want to add the following to your .git/config:

Mark> [b4]
Mark>     midmask = https://inbox.sourceware.org/gdb-patches/%s
Mark>     linkmask = https://inbox.sourceware.org.org/gdb-patches/%s

I also have:

	searchmask = https://inbox.sourceware.org/gdb-patches/all/?x=m&t=1&q=%s

Do I not need this?

I tried b4 today to add reviewed-by trailers from email to a patch of
mine.  I had to look up the message-id (and I guess I wouldn't even have
to do that if I used b4 to send it -- going to try that) and then 'b4
trailers' applied it without any trouble.  Nice to use.

Tom

Re: Any concrete plans after the GDB BoF?

[Lancelot SIX]

> b4 acts a little different from git-pw. It uses Message-IDs to fetch
> patches (and/or a whole thread as mbox). So it helps if your mta
> displays those prominently. If you use emacs you might be interested
> in piem: https://git.kyleam.com/piem/about/
> 
> For gdb-patches you want to add the following to your .git/config:
> 
> [b4]
>     midmask = https://inbox.sourceware.org/gdb-patches/%s
>     linkmask = https://inbox.sourceware.org.org/gdb-patches/%s
> 
> There is a command line example in this presentation:
> https://gnu.wildebeest.org/~mark/fsf-sourceware/presentation.html#slide14
> 
> The latest b4 can also interact with patchwork, but I haven't tried
> that out yet. The new settings are described at:
> https://b4.docs.kernel.org/en/latest/config.html#patchwork-integration-settings
> 

Thanks for the pointers!

I usually use mutt, so having the message id shown is quite easy (if it
can help someone, I have "unignore Message-Id:" in my muttrc file).

I'll play around with this, it might fit slightly better in my workflow
than git-pw.

Best,
Lancelot.

Re: Any concrete plans after the GDB BoF?

[Mark Wielaard]

Hi Tom,

On Mon, Jan 30, 2023 at 02:08:18PM -0700, Tom Tromey wrote:
> >>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:
> 
> Mark> For gdb-patches you want to add the following to your .git/config:
> 
> Mark> [b4]
> Mark>     midmask = https://inbox.sourceware.org/gdb-patches/%s
> Mark>     linkmask = https://inbox.sourceware.org.org/gdb-patches/%s

Note the typo in the second line. It has double org.org. Obviously
should be single .org.

> I also have:
> 
> 	searchmask = https://inbox.sourceware.org/gdb-patches/all/?x=m&t=1&q=%s
> 
> Do I not need this?

Interesting. This is a new setting for using a global search index on
the public-inbox instance. If we had that on inbox.sourceware.org the
URL would be: https://inbox.sourceware.org/all/?x=m&t=1&q=%s I am not
sure which functionality of b4 this matches to.  It would help with
searches of references of a commit on other mailinglists.
If it is just for the gdb-patches list then the URL would be
https://inbox.sourceware.org/gdb-patches/?x=m&t=1&q=%s

Having a full global text search for all lists is slightly heavy (it
is a full text index by xapian. If you can figure out what it
precisely is used for then we have to see how much extra disk space is
needed for that.

If it is just for text searching of auxiliary lists then the following
might all that is needed:
https://inbox.sourceware.org/binutils/?x=m&t=1&q=%s
(aka, text search just the binutils list)

Cheers,

Mark

Re: Any concrete plans after the GDB BoF?

[Andrew Burgess]

Simon Marchi via Gdb <gdb@sourceware.org> writes:

> On 10/31/22 09:37, Joel Brobecker via Gdb wrote:
>>> I agree with all you said.  There is always some resistance related to
>>> how clang-format handles this or that case.  In my opinion, that's minor
>>> compared to the benefit of using it.  My opinion would be: make the
>>> clang-format config that is closest to our style today, make a big
>>> re-format, and carry on.
>> 
>> I agree with that. As long as the formatting is consistent, it might
>> take a little getting used to, but I think we'll be happier if we don't
>> have to spend time worrying about code formatting.
>> 
>> The one small obstacle, perhaps, might be if different versions of
>> the tool format things differently. In that case, we might have to
>> clearly state which version we expect the code to be formatted with.
>> I am thinking of the kind of issues we get with the configury which
>> is generated by the auto tools, which is so dependent on the version
>> that even the distro-provided versions introduce spurious differences
>> sometimes, as a result of which I have built my own set of vanilla
>> autotools. If clang-format is tricky to build, we may have issues
>> in that respect...
>
> I would suggest mandating one version, and for that version to
> continuously be the latest stable version of clang-format, like we do
> for Black.  When a new version comes out, we don't have to wonder if /
> when we move the next version.  Someone just pushes a patch re-formating
> the code to the next version, if there are some differences.  It keeps
> the overhead to a minimum.

I dislike our policy of using the latest version of black, and would
argue that always using the latest version _increases_ the overhead,
rather than reducing it.

My thinking is this; not every one is using a distro that quickly
packages the latest version.  This means that if we are always chasing
the latest version, at least some people will end up continually having
to build clang-format on a regular basis just so they can push to GDB.

If I had a choice then, personally, I'd vote against using clang-format
at all, but it feels like there's a majority in favour, so if we do have
to go down this route, I'd rather we adopted the same policy as for
autotools and C++ versioning.  That is, pick something that works for
us, and commit to it over the medium term.  That way at least, I can
build a single version of clang-format and know that it's going to last
me for a while.

>
> So far I have never seen problems related to distro-specific patches, as
> we have seen with autoconf.
>
> For Debian/Ubuntu, it's easy to get the latest stable version through
> apt.llvm.org.  I don't really know about other distros.  In any case,
> it's easy to build and not long (not long like building the whole
> llvm/clang):
>
> $ git clone --depth 1 https://github.com/llvm/llvm-project.git --branch release/15.x
> $ mkdir -p llvm-project/build
> $ cd llvm-project/build
> $ cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles" ../llvm -DCMAKE_INSTALL_PREFIX=/tmp/llvm
> $ make -j 4 clang-format
> $ make install-clang-format
> $ /tmp/llvm/bin/clang-format --version
> clang-format version 15.0.4 (https://github.com/llvm/llvm-project.git 08bd84e8a6358eb412fcef279f8875e2d69a3374)

Could we build something like this into the GDB makefile maybe?  That
way folk don't need to go looking for this information.

Thanks,
Andrew


>
> Simon

Re: Any concrete plans after the GDB BoF?

[Mark Wielaard]

Hi Andrew,

On Sat, Feb 11, 2023 at 05:13:37PM +0000, Andrew Burgess wrote:
> Simon Marchi via Gdb <gdb@sourceware.org> writes:
> > I would suggest mandating one version, and for that version to
> > continuously be the latest stable version of clang-format, like we do
> > for Black.  When a new version comes out, we don't have to wonder if /
> > when we move the next version.  Someone just pushes a patch re-formating
> > the code to the next version, if there are some differences.  It keeps
> > the overhead to a minimum.
> 
> I dislike our policy of using the latest version of black, and would
> argue that always using the latest version _increases_ the overhead,
> rather than reducing it.

Have you found the python formatting flagged by black "unstable"?  The
buildbot uses the latest black as comes with fedora stable and I don't
remember it flagging issues on upgrades. But maybe it hasn't been
running for long enough? It has been running since July last year. Are
you running a much older black? Does it produce different formatting?
 
> If I had a choice then, personally, I'd vote against using clang-format
> at all, but it feels like there's a majority in favour, so if we do have
> to go down this route, I'd rather we adopted the same policy as for
> autotools and C++ versioning.  That is, pick something that works for
> us, and commit to it over the medium term.  That way at least, I can
> build a single version of clang-format and know that it's going to last
> me for a while.

But is there already a verions that works? I think that is the
difference between the python black formatter for python code and the
clang-format for C and C++ code. It seems for the python code there is
a supported format that matches what is used, but for clang-format
there is not (yet?).

Cheers,

Mark

Re: Any concrete plans after the GDB BoF?

[Andrew Burgess]

Mark Wielaard <mark@klomp.org> writes:

> Hi Andrew,
>
> On Sat, Feb 11, 2023 at 05:13:37PM +0000, Andrew Burgess wrote:
>> Simon Marchi via Gdb <gdb@sourceware.org> writes:
>> > I would suggest mandating one version, and for that version to
>> > continuously be the latest stable version of clang-format, like we do
>> > for Black.  When a new version comes out, we don't have to wonder if /
>> > when we move the next version.  Someone just pushes a patch re-formating
>> > the code to the next version, if there are some differences.  It keeps
>> > the overhead to a minimum.
>> 
>> I dislike our policy of using the latest version of black, and would
>> argue that always using the latest version _increases_ the overhead,
>> rather than reducing it.
>
> Have you found the python formatting flagged by black "unstable"?

No.

>                                                                    The
> buildbot uses the latest black as comes with fedora stable and I don't
> remember it flagging issues on upgrades. But maybe it hasn't been
> running for long enough? It has been running since July last year. Are
> you running a much older black? Does it produce different formatting?

No.  And we don't have a huge volume of Python code.  Both of these
points (stability + small code size) is why I've never said anything.
That doesn't mean I think the idea of constantly chasing the latest
version is a good idea.

In fact, it probably makes it worse.  I _don't_ update black.  Why?
Because what I have just works.  When something does change I'll
certainly commit some incorrectly formatted code.

Does that really matter?  I don't think so.  It'll be an easy fix, it's
just annoying.

>  
>> If I had a choice then, personally, I'd vote against using clang-format
>> at all, but it feels like there's a majority in favour, so if we do have
>> to go down this route, I'd rather we adopted the same policy as for
>> autotools and C++ versioning.  That is, pick something that works for
>> us, and commit to it over the medium term.  That way at least, I can
>> build a single version of clang-format and know that it's going to last
>> me for a while.
>
> But is there already a verions that works? I think that is the
> difference between the python black formatter for python code and the
> clang-format for C and C++ code. It seems for the python code there is
> a supported format that matches what is used, but for clang-format
> there is not (yet?).

I'm a little confused by your point here.  You (correctly) point out
above that the output from black is pretty stable across versions.

But here it almost seems like you're suggesting that we should chase the
latest clang-format because it doesn't (currently) support the style we
use.  Which would seem to suggest we are hoping it _will_ change, which
suggests output instability, which, surely, is a bad thing?  But like I
said, I didn't really understand the question here...

I would suggest that if we did start using clang-format, then that
indicates we are happy enough with its output.  If we're happy enough
with its output today then I think we can be happy with the output for 1
(or even 2) years before looking to see if an updated version offers
improved formatting.

Remember, there are folk who maintain out of tree forks of GDB.  And
though we shouldn't make policy choices just to accommodate them, I'd
hate for us to go out of our way to make their lives harder just for the
sake of chasing the latest version of some tool.

Thanks,
Andrew

Re: Any concrete plans after the GDB BoF?

[Luis Machado]

On 2/13/23 11:54, Andrew Burgess via Gdb wrote:
> Mark Wielaard <mark@klomp.org> writes:
> 
>> Hi Andrew,
>>
>> On Sat, Feb 11, 2023 at 05:13:37PM +0000, Andrew Burgess wrote:
>>> Simon Marchi via Gdb <gdb@sourceware.org> writes:
>>>> I would suggest mandating one version, and for that version to
>>>> continuously be the latest stable version of clang-format, like we do
>>>> for Black.  When a new version comes out, we don't have to wonder if /
>>>> when we move the next version.  Someone just pushes a patch re-formating
>>>> the code to the next version, if there are some differences.  It keeps
>>>> the overhead to a minimum.
>>>
>>> I dislike our policy of using the latest version of black, and would
>>> argue that always using the latest version _increases_ the overhead,
>>> rather than reducing it.
>>
>> Have you found the python formatting flagged by black "unstable"?
> 
> No.
> 
>>                                                                     The
>> buildbot uses the latest black as comes with fedora stable and I don't
>> remember it flagging issues on upgrades. But maybe it hasn't been
>> running for long enough? It has been running since July last year. Are
>> you running a much older black? Does it produce different formatting?
> 
> No.  And we don't have a huge volume of Python code.  Both of these
> points (stability + small code size) is why I've never said anything.
> That doesn't mean I think the idea of constantly chasing the latest
> version is a good idea.
> 
> In fact, it probably makes it worse.  I _don't_ update black.  Why?
> Because what I have just works.  When something does change I'll
> certainly commit some incorrectly formatted code.
> 
> Does that really matter?  I don't think so.  It'll be an easy fix, it's
> just annoying.
> 

I suppose that's the point of introducing auto-formatters. If some incorrect formatting is
pushed alongside some code, it is not a big deal. But having to manually chase some format and fix it by hand (as we do now)
before it can go in is potentially worse.

It is also a burden for reviewing. It doesn't seem like the kind of thing people should be doing manually at
this point in time.

Obviously the burden is different for different people and different setups.

>>   
>>> If I had a choice then, personally, I'd vote against using clang-format
>>> at all, but it feels like there's a majority in favour, so if we do have
>>> to go down this route, I'd rather we adopted the same policy as for
>>> autotools and C++ versioning.  That is, pick something that works for
>>> us, and commit to it over the medium term.  That way at least, I can
>>> build a single version of clang-format and know that it's going to last
>>> me for a while.
>>
>> But is there already a verions that works? I think that is the
>> difference between the python black formatter for python code and the
>> clang-format for C and C++ code. It seems for the python code there is
>> a supported format that matches what is used, but for clang-format
>> there is not (yet?).
> 
> I'm a little confused by your point here.  You (correctly) point out
> above that the output from black is pretty stable across versions.
> 
> But here it almost seems like you're suggesting that we should chase the
> latest clang-format because it doesn't (currently) support the style we
> use.  Which would seem to suggest we are hoping it _will_ change, which
> suggests output instability, which, surely, is a bad thing?  But like I
> said, I didn't really understand the question here...
> 
> I would suggest that if we did start using clang-format, then that
> indicates we are happy enough with its output.  If we're happy enough
> with its output today then I think we can be happy with the output for 1
> (or even 2) years before looking to see if an updated version offers
> improved formatting.
> 
> Remember, there are folk who maintain out of tree forks of GDB.  And
> though we shouldn't make policy choices just to accommodate them, I'd
> hate for us to go out of our way to make their lives harder just for the
> sake of chasing the latest version of some tool.

I think Mark's point is just that we haven't settled on a particular gnu-for-clang-format rule set.

Yes, there is a gnu style there already, but we haven't decide if it is good enough or not.

We just need to play with it for a bit and see if people overall think it is good enough.

> 
> Thanks,
> Andrew
> 

Re: Any concrete plans after the GDB BoF?

[Tom Tromey]

Andrew> I dislike our policy of using the latest version of black, and would
Andrew> argue that always using the latest version _increases_ the overhead,
Andrew> rather than reducing it.

For black at least you can 'pip3 install' a new version without a lot of
trouble.  It's also easy to make a virtualenv and isolate it from the
rest of your python work.

It would also be fine by me to change policy on black though.

Tom

Re: Any concrete plans after the GDB BoF?

[Tom Tromey]

Luis> It is also a burden for reviewing. It doesn't seem like the kind
Luis> of thing people should be doing manually at this point in time.

The ability to read the code and change one's style to adapt is a
quality signal to reviewers.  However if that goes away it probably
won't be a huge loss.

Luis> Yes, there is a gnu style there already, but we haven't decide if
Luis> it is good enough or not.

IMO it definitely isn't but feel free to log your findings in the bug.
One of these days I'll dig up the counter-examples that I dislike and do
that myself as well.

Tom

Re: Any concrete plans after the GDB BoF?

[Luis Machado]

On 2/13/23 14:24, Tom Tromey wrote:
> Luis> It is also a burden for reviewing. It doesn't seem like the kind
> Luis> of thing people should be doing manually at this point in time.
> 
> The ability to read the code and change one's style to adapt is a
> quality signal to reviewers.  However if that goes away it probably
> won't be a huge loss.

That's fair. But should we consider the current state of today's helper tools (auto-formatters, code review tools etc) from the perspective of lowering the bar to what is required for new contributors to volunteer some work to gdb?

> 
> Luis> Yes, there is a gnu style there already, but we haven't decide if
> Luis> it is good enough or not.
> 
> IMO it definitely isn't but feel free to log your findings in the bug.
> One of these days I'll dig up the counter-examples that I dislike and do
> that myself as well.

I've used clang-format for another project, and to be honest I didn't find much I couldn't adapt to/get used to.

The worst so far seems to be the comment reflows. They don't always come out in the best way possible. But that may be due to our use of block comments.

In terms of readability, one could argue some of the C++ constructs in the code aren't that obvious either. But they're convenient, so worth the effort to get over the syntax.

> 
> Tom

Re: Any concrete plans after the GDB BoF?

[Andrew Burgess]

Luis Machado <luis.machado@arm.com> writes:

> On 2/13/23 11:54, Andrew Burgess via Gdb wrote:
>> Mark Wielaard <mark@klomp.org> writes:
>> 
>>> Hi Andrew,
>>>
>>> On Sat, Feb 11, 2023 at 05:13:37PM +0000, Andrew Burgess wrote:
>>>> Simon Marchi via Gdb <gdb@sourceware.org> writes:
>>>>> I would suggest mandating one version, and for that version to
>>>>> continuously be the latest stable version of clang-format, like we do
>>>>> for Black.  When a new version comes out, we don't have to wonder if /
>>>>> when we move the next version.  Someone just pushes a patch re-formating
>>>>> the code to the next version, if there are some differences.  It keeps
>>>>> the overhead to a minimum.
>>>>
>>>> I dislike our policy of using the latest version of black, and would
>>>> argue that always using the latest version _increases_ the overhead,
>>>> rather than reducing it.
>>>
>>> Have you found the python formatting flagged by black "unstable"?
>> 
>> No.
>> 
>>>                                                                     The
>>> buildbot uses the latest black as comes with fedora stable and I don't
>>> remember it flagging issues on upgrades. But maybe it hasn't been
>>> running for long enough? It has been running since July last year. Are
>>> you running a much older black? Does it produce different formatting?
>> 
>> No.  And we don't have a huge volume of Python code.  Both of these
>> points (stability + small code size) is why I've never said anything.
>> That doesn't mean I think the idea of constantly chasing the latest
>> version is a good idea.
>> 
>> In fact, it probably makes it worse.  I _don't_ update black.  Why?
>> Because what I have just works.  When something does change I'll
>> certainly commit some incorrectly formatted code.
>> 
>> Does that really matter?  I don't think so.  It'll be an easy fix, it's
>> just annoying.
>> 
>
> I suppose that's the point of introducing auto-formatters. If some incorrect formatting is
> pushed alongside some code, it is not a big deal. But having to manually chase some format and fix it by hand (as we do now)
> before it can go in is potentially worse.
>
> It is also a burden for reviewing. It doesn't seem like the kind of thing people should be doing manually at
> this point in time.

I've never bought this argument.

This makes perfect sense in a corporate environment, where you can know
everyone is using the same tools.  But for a distributed project, I
don't think we can rely on every contributor using, or remembering to
use the formatting tools correctly.

Ideally we don't want every commit, or a daily commit, where someone
runs clang-format and posts the fix (obviously this will happen, but the
goal would be to keep this to a minimum, right?), so reviewers still
need to think about formatting when reviewing patches.

For larger patches, this is easy enough, I install the patch in my local
tree, run clang-format, and if any changes show up, I immediately reject
the patch.  But I _still_ have to think about formatting, I just do
different things.

For smaller patches that I might previously have reviewed in my email
client; well now I _really_ need to think about formatting, because if I
see anything that's even slightly weird, I can no longer make a
judgement call on if it's formatted reasonably, I absolutely _have_ to
install the patch and clang-format it in order to check it was formatted
correctly.

Now, where this might save time is if we had some kind of git hook which
could validate the code was formatted correctly and reject push attempts
if they are not formatted.  Then I could stop thinking about
formatting.  But until then .... I don't think reviewers will be able to
stop asking: is this formatted correctly?

Thanks,
Andrew

>
> Obviously the burden is different for different people and different setups.
>
>>>   
>>>> If I had a choice then, personally, I'd vote against using clang-format
>>>> at all, but it feels like there's a majority in favour, so if we do have
>>>> to go down this route, I'd rather we adopted the same policy as for
>>>> autotools and C++ versioning.  That is, pick something that works for
>>>> us, and commit to it over the medium term.  That way at least, I can
>>>> build a single version of clang-format and know that it's going to last
>>>> me for a while.
>>>
>>> But is there already a verions that works? I think that is the
>>> difference between the python black formatter for python code and the
>>> clang-format for C and C++ code. It seems for the python code there is
>>> a supported format that matches what is used, but for clang-format
>>> there is not (yet?).
>> 
>> I'm a little confused by your point here.  You (correctly) point out
>> above that the output from black is pretty stable across versions.
>> 
>> But here it almost seems like you're suggesting that we should chase the
>> latest clang-format because it doesn't (currently) support the style we
>> use.  Which would seem to suggest we are hoping it _will_ change, which
>> suggests output instability, which, surely, is a bad thing?  But like I
>> said, I didn't really understand the question here...
>> 
>> I would suggest that if we did start using clang-format, then that
>> indicates we are happy enough with its output.  If we're happy enough
>> with its output today then I think we can be happy with the output for 1
>> (or even 2) years before looking to see if an updated version offers
>> improved formatting.
>> 
>> Remember, there are folk who maintain out of tree forks of GDB.  And
>> though we shouldn't make policy choices just to accommodate them, I'd
>> hate for us to go out of our way to make their lives harder just for the
>> sake of chasing the latest version of some tool.
>
> I think Mark's point is just that we haven't settled on a particular gnu-for-clang-format rule set.
>
> Yes, there is a gnu style there already, but we haven't decide if it is good enough or not.
>
> We just need to play with it for a bit and see if people overall think it is good enough.

OK.

Thanks,
Andrew

>
>> 
>> Thanks,
>> Andrew
>> 

Re: Any concrete plans after the GDB BoF?

[Luis Machado]

On 2/13/23 15:13, Andrew Burgess wrote:
> Luis Machado <luis.machado@arm.com> writes:
> 
>> On 2/13/23 11:54, Andrew Burgess via Gdb wrote:
>>> Mark Wielaard <mark@klomp.org> writes:
>>>
>>>> Hi Andrew,
>>>>
>>>> On Sat, Feb 11, 2023 at 05:13:37PM +0000, Andrew Burgess wrote:
>>>>> Simon Marchi via Gdb <gdb@sourceware.org> writes:
>>>>>> I would suggest mandating one version, and for that version to
>>>>>> continuously be the latest stable version of clang-format, like we do
>>>>>> for Black.  When a new version comes out, we don't have to wonder if /
>>>>>> when we move the next version.  Someone just pushes a patch re-formating
>>>>>> the code to the next version, if there are some differences.  It keeps
>>>>>> the overhead to a minimum.
>>>>>
>>>>> I dislike our policy of using the latest version of black, and would
>>>>> argue that always using the latest version _increases_ the overhead,
>>>>> rather than reducing it.
>>>>
>>>> Have you found the python formatting flagged by black "unstable"?
>>>
>>> No.
>>>
>>>>                                                                      The
>>>> buildbot uses the latest black as comes with fedora stable and I don't
>>>> remember it flagging issues on upgrades. But maybe it hasn't been
>>>> running for long enough? It has been running since July last year. Are
>>>> you running a much older black? Does it produce different formatting?
>>>
>>> No.  And we don't have a huge volume of Python code.  Both of these
>>> points (stability + small code size) is why I've never said anything.
>>> That doesn't mean I think the idea of constantly chasing the latest
>>> version is a good idea.
>>>
>>> In fact, it probably makes it worse.  I _don't_ update black.  Why?
>>> Because what I have just works.  When something does change I'll
>>> certainly commit some incorrectly formatted code.
>>>
>>> Does that really matter?  I don't think so.  It'll be an easy fix, it's
>>> just annoying.
>>>
>>
>> I suppose that's the point of introducing auto-formatters. If some incorrect formatting is
>> pushed alongside some code, it is not a big deal. But having to manually chase some format and fix it by hand (as we do now)
>> before it can go in is potentially worse.
>>
>> It is also a burden for reviewing. It doesn't seem like the kind of thing people should be doing manually at
>> this point in time.
> 
> I've never bought this argument.
> 
> This makes perfect sense in a corporate environment, where you can know
> everyone is using the same tools.  But for a distributed project, I
> don't think we can rely on every contributor using, or remembering to
> use the formatting tools correctly.
> 
> Ideally we don't want every commit, or a daily commit, where someone
> runs clang-format and posts the fix (obviously this will happen, but the
> goal would be to keep this to a minimum, right?), so reviewers still
> need to think about formatting when reviewing patches.
> 
> For larger patches, this is easy enough, I install the patch in my local
> tree, run clang-format, and if any changes show up, I immediately reject
> the patch.  But I _still_ have to think about formatting, I just do
> different things.
> 
> For smaller patches that I might previously have reviewed in my email
> client; well now I _really_ need to think about formatting, because if I
> see anything that's even slightly weird, I can no longer make a
> judgement call on if it's formatted reasonably, I absolutely _have_ to
> install the patch and clang-format it in order to check it was formatted
> correctly.
> 
> Now, where this might save time is if we had some kind of git hook which
> could validate the code was formatted correctly and reject push attempts
> if they are not formatted.  Then I could stop thinking about
> formatting.  But until then .... I don't think reviewers will be able to
> stop asking: is this formatted correctly?
> 

That's what I have in mind. Some pre-commit hook that checks/does things. Obviously we're not there yet, but that would be the most convenient way.

I think anything that needs to be checked by hand wouldn't be an improvement compared to the current process.

> Thanks,
> Andrew
> 
>>
>> Obviously the burden is different for different people and different setups.
>>
>>>>    
>>>>> If I had a choice then, personally, I'd vote against using clang-format
>>>>> at all, but it feels like there's a majority in favour, so if we do have
>>>>> to go down this route, I'd rather we adopted the same policy as for
>>>>> autotools and C++ versioning.  That is, pick something that works for
>>>>> us, and commit to it over the medium term.  That way at least, I can
>>>>> build a single version of clang-format and know that it's going to last
>>>>> me for a while.
>>>>
>>>> But is there already a verions that works? I think that is the
>>>> difference between the python black formatter for python code and the
>>>> clang-format for C and C++ code. It seems for the python code there is
>>>> a supported format that matches what is used, but for clang-format
>>>> there is not (yet?).
>>>
>>> I'm a little confused by your point here.  You (correctly) point out
>>> above that the output from black is pretty stable across versions.
>>>
>>> But here it almost seems like you're suggesting that we should chase the
>>> latest clang-format because it doesn't (currently) support the style we
>>> use.  Which would seem to suggest we are hoping it _will_ change, which
>>> suggests output instability, which, surely, is a bad thing?  But like I
>>> said, I didn't really understand the question here...
>>>
>>> I would suggest that if we did start using clang-format, then that
>>> indicates we are happy enough with its output.  If we're happy enough
>>> with its output today then I think we can be happy with the output for 1
>>> (or even 2) years before looking to see if an updated version offers
>>> improved formatting.
>>>
>>> Remember, there are folk who maintain out of tree forks of GDB.  And
>>> though we shouldn't make policy choices just to accommodate them, I'd
>>> hate for us to go out of our way to make their lives harder just for the
>>> sake of chasing the latest version of some tool.
>>
>> I think Mark's point is just that we haven't settled on a particular gnu-for-clang-format rule set.
>>
>> Yes, there is a gnu style there already, but we haven't decide if it is good enough or not.
>>
>> We just need to play with it for a bit and see if people overall think it is good enough.
> 
> OK.
> 
> Thanks,
> Andrew
> 
>>
>>>
>>> Thanks,
>>> Andrew
>>>
> 

Re: Any concrete plans after the GDB BoF?

[Joel Brobecker]

> > Now, where this might save time is if we had some kind of git hook which
> > could validate the code was formatted correctly and reject push attempts
> > if they are not formatted.  Then I could stop thinking about
> > formatting.  But until then .... I don't think reviewers will be able to
> > stop asking: is this formatted correctly?
> > 
> 
> That's what I have in mind. Some pre-commit hook that checks/does
> things. Obviously we're not there yet, but that would be the most
> convenient way.
> 
> I think anything that needs to be checked by hand wouldn't be an
> improvement compared to the current process.

As long as the the tool is able to do the formatting of a given file
using only that one file, the git-hooks are ready. There is a
style_checker option which is currently calling a script that does
nothing. But if we have some tools that check things such as formatting,
copyright header format, etc, it's easy to insert them and reject
the commit.

The problem is that this arrives too late in the process, IMO, because
by then, the review has already gone through. For a formatting issue,
one could argue that the change is trivial, and therefore automatically
re-approved, but this is not ideal.

What we would want is some kind of CI system which, from the moment
the developer proposes a patch, gets the change validated through
the CI. Style-checking is usually quick, so a good candidate for
a CI. But how to integrate that without starting to re-invent
one of those existing Git review or Git hosting systems that already
exist?

What this discussing is showing, IMO, is that the email-based system
of proposing and reviewing patches may be fast and comfortable, but
has some limitations compared to other more modern systems that seem
hard to overcome. We can find technical solutions that overcome those
issues, but each time I try this exercise, I find myself thinking
the problem has already been solved is there for the taking if only
we could accept email-based workflows might be degraded, possibly
to the point where it becomes more productive to use the recommended
interface (e.g. website).

Good or bad, my concern is that the younger generation views emails
as antiquated and at the same time they have grown up learning about
collaboration using systems such as GitLab or GitHub.

I apologize for widening the discussion from code formatter to
review system. It's not how I planned this message when I started
replying, but it seemed natural to add the comment about how we
manage patch submissions and how we do reviews.

-- 
Joel

Re: Any concrete plans after the GDB BoF?

[Mark Wielaard]

Hi Andrew,

On Mon, 2023-02-13 at 11:54 +0000, Andrew Burgess wrote:
> Mark Wielaard <mark@klomp.org> writes:
> 
> > But is there already a verions that works? I think that is the
> > difference between the python black formatter for python code and the
> > clang-format for C and C++ code. It seems for the python code there is
> > a supported format that matches what is used, but for clang-format
> > there is not (yet?).
> 
> I'm a little confused by your point here.  You (correctly) point out
> above that the output from black is pretty stable across versions.
> 
> But here it almost seems like you're suggesting that we should chase the
> latest clang-format because it doesn't (currently) support the style we
> use.  Which would seem to suggest we are hoping it _will_ change, which
> suggests output instability, which, surely, is a bad thing?  But like I
> said, I didn't really understand the question here...

Sorry, I was just observing that I believe the python with black case
and the C and C++ case with clang-format are not the same. I think we
are in agreement that the python case is probably fine (we just
disagree about whether it is future proof - I think we can use whatever
version of black, you are skeptical that the formatting will stay the
same). But for clang-format we don't have a format that seems
acceptable (to at least to some people) and older versions seems to
produce different formatting from newer versions.

Cheers,

Mark

Re: Any concrete plans after the GDB BoF?

[Mark Wielaard]

Hi Luis,

On Mon, 2023-02-13 at 12:52 +0000, Luis Machado wrote:
> I suppose that's the point of introducing auto-formatters. If some incorrect formatting is
> pushed alongside some code, it is not a big deal. But having to manually chase some format and fix it by hand (as we do now)
> before it can go in is potentially worse.
> 
> It is also a burden for reviewing. It doesn't seem like the kind of thing people should be doing manually at
> this point in time.

Note that builder.sourceware.org can help with that. If you push a
patch to a try builder then the gdb-try-fedora-x86_64 builder will run
python black over it (and fail and put a format diff in the output log
if it doesn't match):
https://sourceware.org/git/?p=builder.git;a=blob;f=builder/master.cfg;hb=HEAD#l2735

I am hoping we can automate that with patchwork so that patches will
get a fail marker if they don't pass the format checker.

Cheers,

Mark

Re: Any concrete plans after the GDB BoF?

[Pedro Alves]

On 2023-02-13 12:52 p.m., Luis Machado via Gdb wrote:

> I think Mark's point is just that we haven't settled on a particular gnu-for-clang-format rule set.
> 
> Yes, there is a gnu style there already, but we haven't decide if it is good enough or not.
> 
> We just need to play with it for a bit and see if people overall think it is good enough.

I've voiced this before in private discussions, but I think never in public.  So here goes:

I'm in the:

 "I wouldn't mind using a tool, but I don't think clang-format's current output is good enough"

camp.

Re: Any concrete plans after the GDB BoF?

[Andrew Burgess]

Mark Wielaard <mark@klomp.org> writes:

> Hi Andrew,
>
> On Mon, 2023-02-13 at 11:54 +0000, Andrew Burgess wrote:
>> Mark Wielaard <mark@klomp.org> writes:
>> 
>> > But is there already a verions that works? I think that is the
>> > difference between the python black formatter for python code and the
>> > clang-format for C and C++ code. It seems for the python code there is
>> > a supported format that matches what is used, but for clang-format
>> > there is not (yet?).
>> 
>> I'm a little confused by your point here.  You (correctly) point out
>> above that the output from black is pretty stable across versions.
>> 
>> But here it almost seems like you're suggesting that we should chase the
>> latest clang-format because it doesn't (currently) support the style we
>> use.  Which would seem to suggest we are hoping it _will_ change, which
>> suggests output instability, which, surely, is a bad thing?  But like I
>> said, I didn't really understand the question here...
>
> Sorry, I was just observing that I believe the python with black case
> and the C and C++ case with clang-format are not the same. I think we
> are in agreement that the python case is probably fine

Just for the record, my concerns about using a tool to format C/C++ code
hold just as much for Python (i.e. I don't really think our current use
of black is "fine"), but I just don't care enough to express an opinion
(before now).

>                                                         (we just
> disagree about whether it is future proof - I think we can use whatever
> version of black, you are skeptical that the formatting will stay the
> same). But for clang-format we don't have a format that seems
> acceptable (to at least to some people) and older versions seems to
> produce different formatting from newer versions.

I'd assumed the output of clang-format would be mostly stable, if that's
known not to be true then I think that's a stronger argument for using a
known version.

Thanks,
Andrew

Re: Any concrete plans after the GDB BoF?

[Andrew Burgess]

Joel Brobecker <brobecker@adacore.com> writes:

>> > Now, where this might save time is if we had some kind of git hook which
>> > could validate the code was formatted correctly and reject push attempts
>> > if they are not formatted.  Then I could stop thinking about
>> > formatting.  But until then .... I don't think reviewers will be able to
>> > stop asking: is this formatted correctly?
>> > 
>> 
>> That's what I have in mind. Some pre-commit hook that checks/does
>> things. Obviously we're not there yet, but that would be the most
>> convenient way.
>> 
>> I think anything that needs to be checked by hand wouldn't be an
>> improvement compared to the current process.
>
> As long as the the tool is able to do the formatting of a given file
> using only that one file, the git-hooks are ready. There is a
> style_checker option which is currently calling a script that does
> nothing. But if we have some tools that check things such as formatting,
> copyright header format, etc, it's easy to insert them and reject
> the commit.
>
> The problem is that this arrives too late in the process, IMO, because
> by then, the review has already gone through. For a formatting issue,
> one could argue that the change is trivial, and therefore automatically
> re-approved, but this is not ideal.

Whether the commit should be reformatted and auto-approved is orthogonal
I think to whether we should have an auto-format checked as part of the
commit hook.

As long as folk are able to manually push to master then the process is
open to (honest) user mistakes, and we should, as far as possible aim to
have systems in place to guard against those mistakes.

So having git refuse to accept a commit that is incorrectly formatted
would be a good thing; though I 100% agree with you that ideally we
would ALSO have tools that could auto-check the formatting earlier in
the process and bring that to the developers attention.

>
> What we would want is some kind of CI system which, from the moment
> the developer proposes a patch, gets the change validated through
> the CI. Style-checking is usually quick, so a good candidate for
> a CI. But how to integrate that without starting to re-invent
> one of those existing Git review or Git hosting systems that already
> exist?
>
> What this discussing is showing, IMO, is that the email-based system
> of proposing and reviewing patches may be fast and comfortable, but
> has some limitations compared to other more modern systems that seem
> hard to overcome. We can find technical solutions that overcome those
> issues, but each time I try this exercise, I find myself thinking
> the problem has already been solved is there for the taking if only
> we could accept email-based workflows might be degraded, possibly
> to the point where it becomes more productive to use the recommended
> interface (e.g. website).

100% agree.

>
> Good or bad, my concern is that the younger generation views emails
> as antiquated and at the same time they have grown up learning about
> collaboration using systems such as GitLab or GitHub.

I'd avoid the word 'antiquated' as it (too me) seems to have negative
connotations.

But I agree, many developers are familiar with a pull-request
development model, and I think it has many advantages over our current
way of doing things, I'd be very much in favour of switching to a PR
style system.

That doesn't mean there aren't also advantages to how we do things
today.

Thanks,
Andrew

Re: Any concrete plans after the GDB BoF?

[Joel Brobecker]

> > As long as the the tool is able to do the formatting of a given file
> > using only that one file, the git-hooks are ready. There is a
> > style_checker option which is currently calling a script that does
> > nothing. But if we have some tools that check things such as formatting,
> > copyright header format, etc, it's easy to insert them and reject
> > the commit.
> >
> > The problem is that this arrives too late in the process, IMO, because
> > by then, the review has already gone through. For a formatting issue,
> > one could argue that the change is trivial, and therefore automatically
> > re-approved, but this is not ideal.
> 
> Whether the commit should be reformatted and auto-approved is orthogonal
> I think to whether we should have an auto-format checked as part of the
> commit hook.
> 
> As long as folk are able to manually push to master then the process is
> open to (honest) user mistakes, and we should, as far as possible aim to
> have systems in place to guard against those mistakes.
> 
> So having git refuse to accept a commit that is incorrectly formatted
> would be a good thing; though I 100% agree with you that ideally we
> would ALSO have tools that could auto-check the formatting earlier in
> the process and bring that to the developers attention.

Agreed. If we want to ensure correct formatting, we need to check for it
before the commit gets pushed. The earlier, the better.

> > Good or bad, my concern is that the younger generation views emails
> > as antiquated and at the same time they have grown up learning about
> > collaboration using systems such as GitLab or GitHub.
> 
> I'd avoid the word 'antiquated' as it (too me) seems to have negative
> connotations.

I agree with that, and was only using this word in the context of
me putting myself in the shoes of those who shared this feedback
with me. Personally, I love email. But truly, some of the younger
generation I talked to simply do not understand our reluctance to
switch to what they believe to be superior technology. As far as
code collaboration goes, they truly see email as a thing of the past.

Having gone through a transition from email-based review to reviews
through a dedicated system, I have to say that it hurt at first,
but generally speaking, I think it was a huge boost overall.

> But I agree, many developers are familiar with a pull-request
> development model, and I think it has many advantages over our current
> way of doing things, I'd be very much in favour of switching to a PR
> style system.
> 
> That doesn't mean there aren't also advantages to how we do things
> today.

Agreed also.

-- 
Joel

Re: Any concrete plans after the GDB BoF?

[Mark Wielaard]

Hi,

On Wed, Feb 15, 2023 at 02:47:35PM +0000, Andrew Burgess wrote:
> > Good or bad, my concern is that the younger generation views emails
> > as antiquated and at the same time they have grown up learning about
> > collaboration using systems such as GitLab or GitHub.
> 
> I'd avoid the word 'antiquated' as it (too me) seems to have negative
> connotations.
> 
> But I agree, many developers are familiar with a pull-request
> development model, and I think it has many advantages over our current
> way of doing things, I'd be very much in favour of switching to a PR
> style system.
> 
> That doesn't mean there aren't also advantages to how we do things
> today.

Yes. What I really like is that email based discussions of patches
makes it a real conversation about what we are doing. So I don't want
to loose that. But I do like some of the automation, especially
pre-commit testing and patch tracking.

Fact is that some people do find it hard to sent patches through
email. And if they don't submit the patch in the first place, there is
no conversation to be had.

For those that are comfortable with git (a requirement for many
projects these days), but get stuck on setting up git send-email or
attaching their patch in their email client, I would recommend
pointing new developers at the sourceware sourcehut mirror:
https://sr.ht/~sourceware/binutils-gdb

There they can interact with the repository through a website and let
sr.ht sent the patches for them (it will use git send-email for them,
but they can just click together their "pull request". And we get a
nice correctly formatted patch email that can then be discussed as
normal.

Some of the automation to test patches early is now provided by
builder.sourceware.org where you can push any patch to a user try
branch to make sure it at leasts builds, has correct python
formatting, and passes a subset of the testsuite on ~10 different
distros/arches.
https://builder.sourceware.org/buildbot/#/builders?tags=gdb-try

git-pw and b4 make it easy to interact with patchwork.sourceware.org
and inbox.sourceware.org.

The missing piece is connecting patchwork and buildbot so you have a
nice overview of which tests a patch passed/failed.

This is really what the Sourceware infrastructure roadmap is about
https://lwn.net/Articles/898655/

We aren't fully there yet, but are making nice progress
https://www.fsf.org/events/sourceware-infrastructure-a-presentation-and-community-q-a

Cheers,

Mark

Re: Any concrete plans after the GDB BoF?

[Joel Brobecker]

> Yes. What I really like is that email based discussions of patches
> makes it a real conversation about what we are doing. So I don't want
> to loose that.

I really feel this is missing the point of what I am trying to explain.
I agree, email discussions make it a real conversation. But that's not
the *only* way to have a conversation about a patch. GitHub is one
example of that, where code-specific comments can be sent, and
more general discussions can also occur at the same time. This
requirement is not difficult to fullfil.

What I can understand people being after (at least what I initially
mourned) is the convenience of receiving an email when something
new happened, and the convenience of being able to just reply to
that email to send their comment. But I have found in practice that
following the link provided in the email is inconsequential, and
in return, the web interface opens doors to lots of things one
cannot do with a simple email.

There are not a whole lot of hosting platforms out there, so my concern
is that, by making email integration a requirement, you're automatically
eliminating a number of solutions which could answer your requirements
just as well, only just differently, and from there, lose some great
features out there.

-- 
Joel

Re: Any concrete plans after the GDB BoF?

[Eli Zaretskii]

> Date: Thu, 16 Feb 2023 14:16:21 +0400
> Cc: Andrew Burgess <aburgess@redhat.com>,
>  Joel Brobecker <brobecker@adacore.com>,
>  Luis Machado <luis.machado@arm.com>, Simon Marchi <simark@simark.ca>,
>  Simon Marchi via Gdb <gdb@sourceware.org>
> From: Joel Brobecker via Gdb <gdb@sourceware.org>
> 
> There are not a whole lot of hosting platforms out there, so my concern
> is that, by making email integration a requirement, you're automatically
> eliminating a number of solutions which could answer your requirements
> just as well, only just differently, and from there, lose some great
> features out there.

Please also take into consideration the other side of this: switching
to a web-based discussions makes participation via email all but
impractical.  People tend to answer short answers without quoting the
context, assuming that all the context is visible in the web form
anyway, and that makes email messages undecipherable.  I follow one
such repository, which uses GitHub, for more than a year, and it is
very frustrating.

So if good support for email is not a requirement, we need to consider
the consequences of basically abandoning email entirely.

Re: Any concrete plans after the GDB BoF?

[Joel Brobecker]

> > There are not a whole lot of hosting platforms out there, so my concern
> > is that, by making email integration a requirement, you're automatically
> > eliminating a number of solutions which could answer your requirements
> > just as well, only just differently, and from there, lose some great
> > features out there.
> 
> Please also take into consideration the other side of this: switching
> to a web-based discussions makes participation via email all but
> impractical.  People tend to answer short answers without quoting the
> context, assuming that all the context is visible in the web form
> anyway, and that makes email messages undecipherable.  I follow one
> such repository, which uses GitHub, for more than a year, and it is
> very frustrating.
> 
> So if good support for email is not a requirement, we need to consider
> the consequences of basically abandoning email entirely.

FTAOD, I am not saying that we must abandon email.

I understand what everyone is saying, and I understand the benefits
of email. But aren't we allowing our own experience to unfairly bias
the list of requirements?

Rather than say "email is nice because it provides those nice
properties" therefore "let's keep emails", I think we should say
"let's investigate any solution that preserve the nice properties",
including those that don't do via email. Otherwise, you're putting
the cart before the horses.

If we think that web-based is necessarily bad and hopeless, then
we're closing ourselves to some options where this might not be true.
All I'm saying is that we need to keep an open mind, rather than
corner ourselves by hanging on to one particular tool. You don't
need the tool, you need what the tool does for you.

If we allow ourselves to consider the idea that what's important
is the ease of having discussions, and that perhaps there might be
systems out there where discussions can be fluently had, read,
and reread later, or if we consider the idea that a certain amount
of sacrifice in this area in exchange for a significant-enough amount
of benefits is worth considering, then we open our mind to evaluating
more fairly a number of options which may surprise us, and be a net
gain for us and for the community.

-- 
Joel

Re: Any concrete plans after the GDB BoF?

[Eli Zaretskii]

> Date: Thu, 16 Feb 2023 17:31:33 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Joel Brobecker <brobecker@adacore.com>, mark@klomp.org,
> 	aburgess@redhat.com, luis.machado@arm.com, simark@simark.ca,
> 	gdb@sourceware.org
> 
> > So if good support for email is not a requirement, we need to consider
> > the consequences of basically abandoning email entirely.
> 
> FTAOD, I am not saying that we must abandon email.

I didn't say you did.

> I understand what everyone is saying, and I understand the benefits
> of email. But aren't we allowing our own experience to unfairly bias
> the list of requirements?

I just mentioned the result of switching to the web interface.  I
didn't say we shouldn't switch, and it is not my place to make the
decision anyway.  I just provided a data point that those who do
decide should consider.  Whether it shifts the balance in one or the
other direction is a separate discussion.

> Rather than say "email is nice because it provides those nice
> properties" therefore "let's keep emails", I think we should say
> "let's investigate any solution that preserve the nice properties",
> including those that don't do via email. Otherwise, you're putting
> the cart before the horses.

Sure, I'm not against that method.

Re: Any concrete plans after the GDB BoF?

[anix]

[-- Attachment #1: Type: text/plain, Size: 5018 bytes --]

Dear：
thank you very mach for the program.
the following is description for bug.
# The source code convert between single-precision floating-point(32-bit) and half-precision floating-point (16-bit).
.section .data
m32fp:    .float 142,    580,    36832,  65504
half:    .short 0x5870, 0x6080, 0x787f, 0x7bff
h1:    .short 0, 0 ,0, 0
m1:    .float 0, 0, 0, 0
.section .text
.globl _start
_start:
    nop
    movaps m32fp, %xmm0
    vcvtps2ph $0, %xmm0, h1        #imm8=$0; h1 {m64}


    vcvtph2ps h1, %xmm1
    movups %xmm1, m1
   
next:    movl $1, %eax
    movl $0, %ebx
    int $0x80
# the source code end here.


# results under GNU Debugger (gdb)
(gdb) x/4fw &m32fp
0x804a000:    142    580    36832    65504
(gdb) x/4fw &m1
0x804a020:    142    580    36832    65504
(gdb) x/4fh &half
0x804a010:    22640    24704    30847    31743
(gdb) x/4fh &h1
0x804a018:    22640    24712    30847    31743
(gdb) x/4xw &m32fp
0x804a000:    0x430e0000    0x44110000    0x470fe000    0x477fe000
(gdb) x/4xw &m1
0x804a020:    0x430e0000    0x44110000    0x470fe000    0x477fe000
(gdb) x/4xh &half
0x804a010:    0x5870    0x6080    0x787f    0x7bff
(gdb) x/4xh &h1
0x804a018:    0x5870    0x6088    0x787f    0x7bff
# the results of half-precision data (half, h1) by gdb  are mistakes, or instruct me
# All above under IA-32 , OS is centos (32-bit), GNU as and gdb are  also 32-bit.
hope your return.
                        Niu Wensheng
                         2023.02.16

---Original---
From: "Joel Brobecker via Gdb"<gdb@sourceware.org&gt;
Date: Thu, Feb 16, 2023 12:14 PM
To: "Andrew Burgess"<aburgess@redhat.com&gt;;
Cc: "Joel Brobecker"<brobecker@adacore.com&gt;;"Luis Machado"<luis.machado@arm.com&gt;;"Mark Wielaard"<mark@klomp.org&gt;;"Simon Marchi"<simark@simark.ca&gt;;"Simon Marchi via Gdb"<gdb@sourceware.org&gt;;
Subject: Re: Any concrete plans after the GDB BoF?


&gt; &gt; As long as the the tool is able to do the formatting of a given file
&gt; &gt; using only that one file, the git-hooks are ready. There is a
&gt; &gt; style_checker option which is currently calling a script that does
&gt; &gt; nothing. But if we have some tools that check things such as formatting,
&gt; &gt; copyright header format, etc, it's easy to insert them and reject
&gt; &gt; the commit.
&gt; &gt;
&gt; &gt; The problem is that this arrives too late in the process, IMO, because
&gt; &gt; by then, the review has already gone through. For a formatting issue,
&gt; &gt; one could argue that the change is trivial, and therefore automatically
&gt; &gt; re-approved, but this is not ideal.
&gt; 
&gt; Whether the commit should be reformatted and auto-approved is orthogonal
&gt; I think to whether we should have an auto-format checked as part of the
&gt; commit hook.
&gt; 
&gt; As long as folk are able to manually push to master then the process is
&gt; open to (honest) user mistakes, and we should, as far as possible aim to
&gt; have systems in place to guard against those mistakes.
&gt; 
&gt; So having git refuse to accept a commit that is incorrectly formatted
&gt; would be a good thing; though I 100% agree with you that ideally we
&gt; would ALSO have tools that could auto-check the formatting earlier in
&gt; the process and bring that to the developers attention.

Agreed. If we want to ensure correct formatting, we need to check for it
before the commit gets pushed. The earlier, the better.

&gt; &gt; Good or bad, my concern is that the younger generation views emails
&gt; &gt; as antiquated and at the same time they have grown up learning about
&gt; &gt; collaboration using systems such as GitLab or GitHub.
&gt; 
&gt; I'd avoid the word 'antiquated' as it (too me) seems to have negative
&gt; connotations.

I agree with that, and was only using this word in the context of
me putting myself in the shoes of those who shared this feedback
with me. Personally, I love email. But truly, some of the younger
generation I talked to simply do not understand our reluctance to
switch to what they believe to be superior technology. As far as
code collaboration goes, they truly see email as a thing of the past.

Having gone through a transition from email-based review to reviews
through a dedicated system, I have to say that it hurt at first,
but generally speaking, I think it was a huge boost overall.

&gt; But I agree, many developers are familiar with a pull-request
&gt; development model, and I think it has many advantages over our current
&gt; way of doing things, I'd be very much in favour of switching to a PR
&gt; style system.
&gt; 
&gt; That doesn't mean there aren't also advantages to how we do things
&gt; today.

Agreed also.

-- 
Joel