public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Any concrete plans after the GDB BoF?
@ 2022-10-27 10:47 Luis Machado
  2022-10-28 16:16 ` Simon Marchi
  2022-12-13  2:48 ` Frank Ch. Eigler
  0 siblings, 2 replies; 43+ messages in thread
From: Luis Machado @ 2022-10-27 10:47 UTC (permalink / raw)
  To: gdb

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2022-10-27 10:47 Any concrete plans after the GDB BoF? Luis Machado
@ 2022-10-28 16:16 ` Simon Marchi
  2022-10-28 16:51   ` John Baldwin
  2022-10-31  9:28   ` Luis Machado
  2022-12-13  2:48 ` Frank Ch. Eigler
  1 sibling, 2 replies; 43+ messages in thread
From: Simon Marchi @ 2022-10-28 16:16 UTC (permalink / raw)
  To: Luis Machado, gdb; +Cc: Mark Wielaard

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2022-10-28 16:16 ` Simon Marchi
@ 2022-10-28 16:51   ` John Baldwin
  2022-10-28 16:54     ` Simon Marchi
  2022-10-31  9:28   ` Luis Machado
  1 sibling, 1 reply; 43+ messages in thread
From: John Baldwin @ 2022-10-28 16:51 UTC (permalink / raw)
  To: Simon Marchi, Luis Machado, gdb; +Cc: Mark Wielaard

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2022-10-28 16:51   ` John Baldwin
@ 2022-10-28 16:54     ` Simon Marchi
  0 siblings, 0 replies; 43+ messages in thread
From: Simon Marchi @ 2022-10-28 16:54 UTC (permalink / raw)
  To: John Baldwin, Luis Machado, gdb; +Cc: Mark Wielaard

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2022-10-28 16:16 ` Simon Marchi
  2022-10-28 16:51   ` John Baldwin
@ 2022-10-31  9:28   ` Luis Machado
  2022-10-31 13:17     ` Simon Marchi
                       ` (2 more replies)
  1 sibling, 3 replies; 43+ messages in thread
From: Luis Machado @ 2022-10-31  9:28 UTC (permalink / raw)
  To: Simon Marchi, gdb, John Baldwin; +Cc: Mark Wielaard

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2022-10-31  9:28   ` Luis Machado
@ 2022-10-31 13:17     ` Simon Marchi
  2022-10-31 13:37       ` Joel Brobecker
  2022-12-15 10:17     ` Luis Machado
  2023-01-01 22:02     ` Mark Wielaard
  2 siblings, 1 reply; 43+ messages in thread
From: Simon Marchi @ 2022-10-31 13:17 UTC (permalink / raw)
  To: Luis Machado, gdb, John Baldwin; +Cc: Mark Wielaard



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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2022-10-31 13:17     ` Simon Marchi
@ 2022-10-31 13:37       ` Joel Brobecker
  2022-10-31 14:15         ` Simon Marchi
  0 siblings, 1 reply; 43+ messages in thread
From: Joel Brobecker @ 2022-10-31 13:37 UTC (permalink / raw)
  To: Simon Marchi via Gdb
  Cc: Luis Machado, John Baldwin, Mark Wielaard, 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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2022-10-31 13:37       ` Joel Brobecker
@ 2022-10-31 14:15         ` Simon Marchi
  2022-10-31 17:31           ` Joel Brobecker
  2023-02-11 17:13           ` Andrew Burgess
  0 siblings, 2 replies; 43+ messages in thread
From: Simon Marchi @ 2022-10-31 14:15 UTC (permalink / raw)
  To: Joel Brobecker, Simon Marchi via Gdb; +Cc: Mark Wielaard



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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2022-10-31 14:15         ` Simon Marchi
@ 2022-10-31 17:31           ` Joel Brobecker
  2023-02-11 17:13           ` Andrew Burgess
  1 sibling, 0 replies; 43+ messages in thread
From: Joel Brobecker @ 2022-10-31 17:31 UTC (permalink / raw)
  To: Simon Marchi; +Cc: Joel Brobecker, Simon Marchi via Gdb, Mark Wielaard

> 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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2022-10-27 10:47 Any concrete plans after the GDB BoF? Luis Machado
  2022-10-28 16:16 ` Simon Marchi
@ 2022-12-13  2:48 ` Frank Ch. Eigler
  1 sibling, 0 replies; 43+ messages in thread
From: Frank Ch. Eigler @ 2022-12-13  2:48 UTC (permalink / raw)
  To: Luis Machado; +Cc: gdb

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2022-10-31  9:28   ` Luis Machado
  2022-10-31 13:17     ` Simon Marchi
@ 2022-12-15 10:17     ` Luis Machado
  2023-01-01 22:02     ` Mark Wielaard
  2 siblings, 0 replies; 43+ messages in thread
From: Luis Machado @ 2022-12-15 10:17 UTC (permalink / raw)
  To: Simon Marchi, gdb, John Baldwin; +Cc: Mark Wielaard

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.


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2022-10-31  9:28   ` Luis Machado
  2022-10-31 13:17     ` Simon Marchi
  2022-12-15 10:17     ` Luis Machado
@ 2023-01-01 22:02     ` Mark Wielaard
  2023-01-20 17:30       ` Tom Tromey
  2 siblings, 1 reply; 43+ messages in thread
From: Mark Wielaard @ 2023-01-01 22:02 UTC (permalink / raw)
  To: Luis Machado; +Cc: Simon Marchi, gdb, John Baldwin

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-01-01 22:02     ` Mark Wielaard
@ 2023-01-20 17:30       ` Tom Tromey
  2023-01-20 20:30         ` Tom Tromey
  0 siblings, 1 reply; 43+ messages in thread
From: Tom Tromey @ 2023-01-20 17:30 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: Luis Machado, Simon Marchi, gdb, John Baldwin

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-01-20 17:30       ` Tom Tromey
@ 2023-01-20 20:30         ` Tom Tromey
  2023-01-27 15:50           ` Lancelot SIX
  0 siblings, 1 reply; 43+ messages in thread
From: Tom Tromey @ 2023-01-20 20:30 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Mark Wielaard, Luis Machado, Simon Marchi, gdb, John Baldwin

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-01-20 20:30         ` Tom Tromey
@ 2023-01-27 15:50           ` Lancelot SIX
  2023-01-27 23:50             ` Tom Tromey
  0 siblings, 1 reply; 43+ messages in thread
From: Lancelot SIX @ 2023-01-27 15:50 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Mark Wielaard, Luis Machado, Simon Marchi, gdb, John Baldwin

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.

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-01-27 15:50           ` Lancelot SIX
@ 2023-01-27 23:50             ` Tom Tromey
  2023-01-30 17:43               ` Lancelot SIX
  0 siblings, 1 reply; 43+ messages in thread
From: Tom Tromey @ 2023-01-27 23:50 UTC (permalink / raw)
  To: Lancelot SIX
  Cc: Tom Tromey, Mark Wielaard, Luis Machado, Simon Marchi, gdb, John Baldwin

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-01-27 23:50             ` Tom Tromey
@ 2023-01-30 17:43               ` Lancelot SIX
  2023-01-30 18:46                 ` Mark Wielaard
  0 siblings, 1 reply; 43+ messages in thread
From: Lancelot SIX @ 2023-01-30 17:43 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Mark Wielaard, Luis Machado, Simon Marchi, gdb, John Baldwin

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-01-30 17:43               ` Lancelot SIX
@ 2023-01-30 18:46                 ` Mark Wielaard
  2023-01-30 21:08                   ` Tom Tromey
  2023-01-31 10:00                   ` Lancelot SIX
  0 siblings, 2 replies; 43+ messages in thread
From: Mark Wielaard @ 2023-01-30 18:46 UTC (permalink / raw)
  To: Lancelot SIX; +Cc: Tom Tromey, Luis Machado, Simon Marchi, gdb, John Baldwin

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-01-30 18:46                 ` Mark Wielaard
@ 2023-01-30 21:08                   ` Tom Tromey
  2023-02-04 11:36                     ` Mark Wielaard
  2023-01-31 10:00                   ` Lancelot SIX
  1 sibling, 1 reply; 43+ messages in thread
From: Tom Tromey @ 2023-01-30 21:08 UTC (permalink / raw)
  To: Mark Wielaard
  Cc: Lancelot SIX, Tom Tromey, Luis Machado, Simon Marchi, gdb, John Baldwin

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-01-30 18:46                 ` Mark Wielaard
  2023-01-30 21:08                   ` Tom Tromey
@ 2023-01-31 10:00                   ` Lancelot SIX
  1 sibling, 0 replies; 43+ messages in thread
From: Lancelot SIX @ 2023-01-31 10:00 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: Tom Tromey, Luis Machado, Simon Marchi, gdb, John Baldwin

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-01-30 21:08                   ` Tom Tromey
@ 2023-02-04 11:36                     ` Mark Wielaard
  0 siblings, 0 replies; 43+ messages in thread
From: Mark Wielaard @ 2023-02-04 11:36 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Lancelot SIX, Luis Machado, Simon Marchi, gdb, John Baldwin

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2022-10-31 14:15         ` Simon Marchi
  2022-10-31 17:31           ` Joel Brobecker
@ 2023-02-11 17:13           ` Andrew Burgess
  2023-02-12 12:43             ` Mark Wielaard
  2023-02-13 14:05             ` Tom Tromey
  1 sibling, 2 replies; 43+ messages in thread
From: Andrew Burgess @ 2023-02-11 17:13 UTC (permalink / raw)
  To: Simon Marchi, Joel Brobecker, Simon Marchi via Gdb; +Cc: Mark Wielaard

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-11 17:13           ` Andrew Burgess
@ 2023-02-12 12:43             ` Mark Wielaard
  2023-02-13 11:54               ` Andrew Burgess
  2023-02-13 14:05             ` Tom Tromey
  1 sibling, 1 reply; 43+ messages in thread
From: Mark Wielaard @ 2023-02-12 12:43 UTC (permalink / raw)
  To: Andrew Burgess; +Cc: Simon Marchi, Joel Brobecker, Simon Marchi via Gdb

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-12 12:43             ` Mark Wielaard
@ 2023-02-13 11:54               ` Andrew Burgess
  2023-02-13 12:52                 ` Luis Machado
  2023-02-14 13:00                 ` Mark Wielaard
  0 siblings, 2 replies; 43+ messages in thread
From: Andrew Burgess @ 2023-02-13 11:54 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: Simon Marchi, Joel Brobecker, Simon Marchi via Gdb

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-13 11:54               ` Andrew Burgess
@ 2023-02-13 12:52                 ` Luis Machado
  2023-02-13 14:24                   ` Tom Tromey
                                     ` (3 more replies)
  2023-02-14 13:00                 ` Mark Wielaard
  1 sibling, 4 replies; 43+ messages in thread
From: Luis Machado @ 2023-02-13 12:52 UTC (permalink / raw)
  To: Andrew Burgess, Mark Wielaard
  Cc: Simon Marchi, Joel Brobecker, Simon Marchi via Gdb

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
> 


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-11 17:13           ` Andrew Burgess
  2023-02-12 12:43             ` Mark Wielaard
@ 2023-02-13 14:05             ` Tom Tromey
  1 sibling, 0 replies; 43+ messages in thread
From: Tom Tromey @ 2023-02-13 14:05 UTC (permalink / raw)
  To: Andrew Burgess via Gdb
  Cc: Simon Marchi, Joel Brobecker, Andrew Burgess, Mark Wielaard

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-13 12:52                 ` Luis Machado
@ 2023-02-13 14:24                   ` Tom Tromey
  2023-02-13 14:42                     ` Luis Machado
  2023-02-13 15:13                   ` Andrew Burgess
                                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 43+ messages in thread
From: Tom Tromey @ 2023-02-13 14:24 UTC (permalink / raw)
  To: Luis Machado via Gdb
  Cc: Andrew Burgess, Mark Wielaard, Luis Machado, Simon Marchi,
	Joel Brobecker

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-13 14:24                   ` Tom Tromey
@ 2023-02-13 14:42                     ` Luis Machado
  0 siblings, 0 replies; 43+ messages in thread
From: Luis Machado @ 2023-02-13 14:42 UTC (permalink / raw)
  To: Tom Tromey, Luis Machado via Gdb
  Cc: Andrew Burgess, Mark Wielaard, Simon Marchi, Joel Brobecker

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-13 12:52                 ` Luis Machado
  2023-02-13 14:24                   ` Tom Tromey
@ 2023-02-13 15:13                   ` Andrew Burgess
  2023-02-13 15:23                     ` Luis Machado
  2023-02-14 13:07                   ` Mark Wielaard
  2023-02-14 14:23                   ` Pedro Alves
  3 siblings, 1 reply; 43+ messages in thread
From: Andrew Burgess @ 2023-02-13 15:13 UTC (permalink / raw)
  To: Luis Machado, Mark Wielaard
  Cc: Simon Marchi, Joel Brobecker, Simon Marchi via Gdb

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-13 15:13                   ` Andrew Burgess
@ 2023-02-13 15:23                     ` Luis Machado
  2023-02-14  5:48                       ` Joel Brobecker
  0 siblings, 1 reply; 43+ messages in thread
From: Luis Machado @ 2023-02-13 15:23 UTC (permalink / raw)
  To: Andrew Burgess, Mark Wielaard
  Cc: Simon Marchi, Joel Brobecker, Simon Marchi via Gdb

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-13 15:23                     ` Luis Machado
@ 2023-02-14  5:48                       ` Joel Brobecker
  2023-02-15 14:47                         ` Andrew Burgess
  0 siblings, 1 reply; 43+ messages in thread
From: Joel Brobecker @ 2023-02-14  5:48 UTC (permalink / raw)
  To: Luis Machado
  Cc: Andrew Burgess, Mark Wielaard, Simon Marchi, Joel Brobecker,
	Simon Marchi via Gdb

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-13 11:54               ` Andrew Burgess
  2023-02-13 12:52                 ` Luis Machado
@ 2023-02-14 13:00                 ` Mark Wielaard
  2023-02-15 14:36                   ` Andrew Burgess
  1 sibling, 1 reply; 43+ messages in thread
From: Mark Wielaard @ 2023-02-14 13:00 UTC (permalink / raw)
  To: Andrew Burgess; +Cc: Simon Marchi, Joel Brobecker, Simon Marchi via Gdb

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-13 12:52                 ` Luis Machado
  2023-02-13 14:24                   ` Tom Tromey
  2023-02-13 15:13                   ` Andrew Burgess
@ 2023-02-14 13:07                   ` Mark Wielaard
  2023-02-14 14:23                   ` Pedro Alves
  3 siblings, 0 replies; 43+ messages in thread
From: Mark Wielaard @ 2023-02-14 13:07 UTC (permalink / raw)
  To: Luis Machado, Andrew Burgess
  Cc: Simon Marchi, Joel Brobecker, Simon Marchi via Gdb

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-13 12:52                 ` Luis Machado
                                     ` (2 preceding siblings ...)
  2023-02-14 13:07                   ` Mark Wielaard
@ 2023-02-14 14:23                   ` Pedro Alves
  3 siblings, 0 replies; 43+ messages in thread
From: Pedro Alves @ 2023-02-14 14:23 UTC (permalink / raw)
  To: Luis Machado, Andrew Burgess, Mark Wielaard
  Cc: Simon Marchi, Joel Brobecker, Simon Marchi via Gdb

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.

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-14 13:00                 ` Mark Wielaard
@ 2023-02-15 14:36                   ` Andrew Burgess
  0 siblings, 0 replies; 43+ messages in thread
From: Andrew Burgess @ 2023-02-15 14:36 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: Simon Marchi, Joel Brobecker, Simon Marchi via Gdb

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-14  5:48                       ` Joel Brobecker
@ 2023-02-15 14:47                         ` Andrew Burgess
  2023-02-16  4:14                           ` Joel Brobecker
  2023-02-16  9:51                           ` Mark Wielaard
  0 siblings, 2 replies; 43+ messages in thread
From: Andrew Burgess @ 2023-02-15 14:47 UTC (permalink / raw)
  To: Joel Brobecker, Luis Machado
  Cc: Mark Wielaard, Simon Marchi, Joel Brobecker, Simon Marchi via Gdb

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-15 14:47                         ` Andrew Burgess
@ 2023-02-16  4:14                           ` Joel Brobecker
  2023-02-16  9:51                           ` Mark Wielaard
  1 sibling, 0 replies; 43+ messages in thread
From: Joel Brobecker @ 2023-02-16  4:14 UTC (permalink / raw)
  To: Andrew Burgess
  Cc: Joel Brobecker, Luis Machado, Mark Wielaard, Simon Marchi,
	Simon Marchi via Gdb

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-15 14:47                         ` Andrew Burgess
  2023-02-16  4:14                           ` Joel Brobecker
@ 2023-02-16  9:51                           ` Mark Wielaard
  2023-02-16 10:16                             ` Joel Brobecker
  1 sibling, 1 reply; 43+ messages in thread
From: Mark Wielaard @ 2023-02-16  9:51 UTC (permalink / raw)
  To: Andrew Burgess
  Cc: Joel Brobecker, Luis Machado, Simon Marchi, Simon Marchi via Gdb

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-16  9:51                           ` Mark Wielaard
@ 2023-02-16 10:16                             ` Joel Brobecker
  2023-02-16 11:58                               ` Eli Zaretskii
  0 siblings, 1 reply; 43+ messages in thread
From: Joel Brobecker @ 2023-02-16 10:16 UTC (permalink / raw)
  To: Mark Wielaard
  Cc: Andrew Burgess, Joel Brobecker, Luis Machado, Simon Marchi,
	Simon Marchi via Gdb

> 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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-16 10:16                             ` Joel Brobecker
@ 2023-02-16 11:58                               ` Eli Zaretskii
  2023-02-16 13:31                                 ` Joel Brobecker
  0 siblings, 1 reply; 43+ messages in thread
From: Eli Zaretskii @ 2023-02-16 11:58 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: mark, aburgess, brobecker, luis.machado, simark, gdb

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-16 11:58                               ` Eli Zaretskii
@ 2023-02-16 13:31                                 ` Joel Brobecker
  2023-02-16 15:23                                   ` Eli Zaretskii
  0 siblings, 1 reply; 43+ messages in thread
From: Joel Brobecker @ 2023-02-16 13:31 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Joel Brobecker, mark, aburgess, luis.machado, simark, gdb

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
  2023-02-16 13:31                                 ` Joel Brobecker
@ 2023-02-16 15:23                                   ` Eli Zaretskii
  0 siblings, 0 replies; 43+ messages in thread
From: Eli Zaretskii @ 2023-02-16 15:23 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: mark, aburgess, luis.machado, simark, gdb

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Any concrete plans after the GDB BoF?
@ 2023-02-16  8:53 anix
  0 siblings, 0 replies; 43+ messages in thread
From: anix @ 2023-02-16  8:53 UTC (permalink / raw)
  To: Joel Brobecker, Andrew Burgess
  Cc: Joel Brobecker, Luis Machado, Mark Wielaard, Simon Marchi,
	Simon Marchi via Gdb

[-- 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:
&nbsp; &nbsp; nop
&nbsp; &nbsp; movaps m32fp, %xmm0
&nbsp; &nbsp; vcvtps2ph $0, %xmm0, h1        #imm8=$0; h1 {m64}


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


# results under GNU Debugger (gdb)
(gdb) x/4fw &amp;m32fp
0x804a000:    142    580    36832    65504
(gdb) x/4fw &amp;m1
0x804a020:    142    580    36832    65504
(gdb) x/4fh &amp;half
0x804a010:    22640    24704    30847    31743
(gdb) x/4fh &amp;h1
0x804a018:    22640    24712    30847    31743
(gdb) x/4xw &amp;m32fp
0x804a000:    0x430e0000    0x44110000    0x470fe000    0x477fe000
(gdb) x/4xw &amp;m1
0x804a020:    0x430e0000    0x44110000    0x470fe000    0x477fe000
(gdb) x/4xh &amp;half
0x804a010:    0x5870    0x6080    0x787f    0x7bff
(gdb) x/4xh &amp;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.
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Niu Wensheng
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;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

^ permalink raw reply	[flat|nested] 43+ messages in thread

end of thread, other threads:[~2023-02-16 15:23 UTC | newest]

Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-27 10:47 Any concrete plans after the GDB BoF? Luis Machado
2022-10-28 16:16 ` Simon Marchi
2022-10-28 16:51   ` John Baldwin
2022-10-28 16:54     ` Simon Marchi
2022-10-31  9:28   ` Luis Machado
2022-10-31 13:17     ` Simon Marchi
2022-10-31 13:37       ` Joel Brobecker
2022-10-31 14:15         ` Simon Marchi
2022-10-31 17:31           ` Joel Brobecker
2023-02-11 17:13           ` Andrew Burgess
2023-02-12 12:43             ` Mark Wielaard
2023-02-13 11:54               ` Andrew Burgess
2023-02-13 12:52                 ` Luis Machado
2023-02-13 14:24                   ` Tom Tromey
2023-02-13 14:42                     ` Luis Machado
2023-02-13 15:13                   ` Andrew Burgess
2023-02-13 15:23                     ` Luis Machado
2023-02-14  5:48                       ` Joel Brobecker
2023-02-15 14:47                         ` Andrew Burgess
2023-02-16  4:14                           ` Joel Brobecker
2023-02-16  9:51                           ` Mark Wielaard
2023-02-16 10:16                             ` Joel Brobecker
2023-02-16 11:58                               ` Eli Zaretskii
2023-02-16 13:31                                 ` Joel Brobecker
2023-02-16 15:23                                   ` Eli Zaretskii
2023-02-14 13:07                   ` Mark Wielaard
2023-02-14 14:23                   ` Pedro Alves
2023-02-14 13:00                 ` Mark Wielaard
2023-02-15 14:36                   ` Andrew Burgess
2023-02-13 14:05             ` Tom Tromey
2022-12-15 10:17     ` Luis Machado
2023-01-01 22:02     ` Mark Wielaard
2023-01-20 17:30       ` Tom Tromey
2023-01-20 20:30         ` Tom Tromey
2023-01-27 15:50           ` Lancelot SIX
2023-01-27 23:50             ` Tom Tromey
2023-01-30 17:43               ` Lancelot SIX
2023-01-30 18:46                 ` Mark Wielaard
2023-01-30 21:08                   ` Tom Tromey
2023-02-04 11:36                     ` Mark Wielaard
2023-01-31 10:00                   ` Lancelot SIX
2022-12-13  2:48 ` Frank Ch. Eigler
2023-02-16  8:53 anix

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).