Contributing to gdb

Contributing to gdb

[shaunak saha via Gdb]

Hi all,

I am new to the community and I'd like to contribute to gdb. I have 15
years of development experience in C mainly working in embedded
domain. Went through the project ideas page
"https://sourceware.org/gdb/wiki/ProjectIdeas". I would be interested
to contribute in areas like Embedded Debugging, watchpoints or
internals. Any suggestion would be great.

Regards,
Shaunak

Re: Contributing to gdb

[Guinevere Larsen via Gdb]

On 6/14/24 6:52 PM, shaunak saha via Gdb wrote:
> Hi all,
>
> I am new to the community and I'd like to contribute to gdb. I have 15
> years of development experience in C mainly working in embedded
> domain. Went through the project ideas page
> "https://sourceware.org/gdb/wiki/ProjectIdeas". I would be interested
> to contribute in areas like Embedded Debugging, watchpoints or
> internals. Any suggestion would be great.
>
> Regards,
> Shaunak
>
Hello! Welcome welcome, we always love to have new contributors :)

My first thought with regards to that page is that I don't know how up 
to date it is... the last update seems to be back in 2021, which is from 
before I joined the project. That said, I think there is plenty of 
things to do in the areas you mentioned.

For embedded debugging, unfortunately I have no idea what the situation is.

For watchpoints, the first bug that that page mentions is still open, 
but apparently the last mention of anything related to it was in 2014 
(the 2024 comment is unrelated), so you could first check if you can 
still reproduce the issue, and maybe try to fix or close the bug if it 
can't be reproduced anymore. I'm also a big fan of improving user 
experience, so the second thing about watchpoints (and the misuse of the 
word scope) is something I'd love to see, if you're interested in fixing it.

And for internals, if I may do a bit of promotion of my favorite area, 
right now reverse debugging has a big problem: We rely on recording the 
execution history of the inferior in a global variable, which is totally 
not feasible if someone wants to record multiple inferiors at once. I'd 
love to see a rework of this area that makes the history specific to an 
inferior instead of relying on a global var. This could be pretty 
complicated, as I don't exactly know how someone would go about doing 
this and it might touch a couple different subsystems, but if you'd like 
your first contribution to be tough as nails, I know I would love to see 
it :)


Once you decided on something to work on, if it isn't something that 
feels obvious to you or feels like it could depend on some design 
decisions, I recommend sending a very simple prototype as an RFC to the 
gdb-patches@sourceware list, so people can discuss if your approach 
makes sense.

If you want some help understanding some bits of GDB, feel free to reach 
out on IRC (#gdb on libera chat), and if you feel shy about asking 
questions in public, feel free to reach to me privately :) (though I 
mostly only answer on work hours for Brazil).


Just a heads up, too, if your patch isn't a trivial fix, you might need 
to sign a bit of paperwork giving the copyright of changes to GDB to the 
Free Software Foundation before we are able to accept the changes. I 
mention this up front because I know a few people who were turned off by 
the idea, even though the process itself isn't complicated.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

DCO: Was: Re: Contributing to gdb

[Andrew Pinski via Gdb]

On Mon, Jun 17, 2024 at 5:23 AM Guinevere Larsen via Gdb
<gdb@sourceware.org> wrote:
> Just a heads up, too, if your patch isn't a trivial fix, you might need
> to sign a bit of paperwork giving the copyright of changes to GDB to the
> Free Software Foundation before we are able to accept the changes. I
> mention this up front because I know a few people who were turned off by
> the idea, even though the process itself isn't complicated.

I just noticed that GDB (and binutils) are currently not accepting
DCO's like both glibc
(https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
Has there been any talk about accepting DCOs for gdb and binutils? Or
has this not been brought up yet?

Thanks,
Andrew

>
> --
> Cheers,
> Guinevere Larsen
> She/Her/Hers
>

Re: DCO: Was: Re: Contributing to gdb

[Guinevere Larsen via Gdb]

On 6/17/24 12:00 PM, Andrew Pinski wrote:
> On Mon, Jun 17, 2024 at 5:23 AM Guinevere Larsen via Gdb
> <gdb@sourceware.org> wrote:
>> Just a heads up, too, if your patch isn't a trivial fix, you might need
>> to sign a bit of paperwork giving the copyright of changes to GDB to the
>> Free Software Foundation before we are able to accept the changes. I
>> mention this up front because I know a few people who were turned off by
>> the idea, even though the process itself isn't complicated.
> I just noticed that GDB (and binutils) are currently not accepting
> DCO's like both glibc
> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
> Has there been any talk about accepting DCOs for gdb and binutils? Or
> has this not been brought up yet?

I haven't heard of it yet, every time I see a new contributor with a 
patch accepted, the copyright assignment is always the way everyone 
uses, and it has stalled the last release.

I for one would absolutely love if we could use a quick DCO line instead 
of current process.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

>
> Thanks,
> Andrew
>
>> --
>> Cheers,
>> Guinevere Larsen
>> She/Her/Hers
>>

Re: DCO: Was: Re: Contributing to gdb

[Jan Beulich via Gdb]

On 17.06.2024 17:57, Guinevere Larsen wrote:
> On 6/17/24 12:00 PM, Andrew Pinski wrote:
>> On Mon, Jun 17, 2024 at 5:23 AM Guinevere Larsen via Gdb
>> <gdb@sourceware.org> wrote:
>>> Just a heads up, too, if your patch isn't a trivial fix, you might need
>>> to sign a bit of paperwork giving the copyright of changes to GDB to the
>>> Free Software Foundation before we are able to accept the changes. I
>>> mention this up front because I know a few people who were turned off by
>>> the idea, even though the process itself isn't complicated.
>> I just noticed that GDB (and binutils) are currently not accepting
>> DCO's like both glibc
>> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
>> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
>> Has there been any talk about accepting DCOs for gdb and binutils? Or
>> has this not been brought up yet?
> 
> I haven't heard of it yet, every time I see a new contributor with a 
> patch accepted, the copyright assignment is always the way everyone 
> uses, and it has stalled the last release.
> 
> I for one would absolutely love if we could use a quick DCO line instead 
> of current process.

Yet binutils/MAINTAINERS already mentions this as a possibility.

Jan

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii via Gdb]

> Date: Mon, 17 Jun 2024 12:57:41 -0300
> Cc: GDB Development <gdb@sourceware.org>, binutils <binutils@sourceware.org>
> From: Guinevere Larsen via Gdb <gdb@sourceware.org>
> 
> On 6/17/24 12:00 PM, Andrew Pinski wrote:
> > On Mon, Jun 17, 2024 at 5:23 AM Guinevere Larsen via Gdb
> > <gdb@sourceware.org> wrote:
> >> Just a heads up, too, if your patch isn't a trivial fix, you might need
> >> to sign a bit of paperwork giving the copyright of changes to GDB to the
> >> Free Software Foundation before we are able to accept the changes. I
> >> mention this up front because I know a few people who were turned off by
> >> the idea, even though the process itself isn't complicated.
> > I just noticed that GDB (and binutils) are currently not accepting
> > DCO's like both glibc
> > (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
> > and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
> > Has there been any talk about accepting DCOs for gdb and binutils? Or
> > has this not been brought up yet?
> 
> I haven't heard of it yet, every time I see a new contributor with a 
> patch accepted, the copyright assignment is always the way everyone 
> uses, and it has stalled the last release.
> 
> I for one would absolutely love if we could use a quick DCO line instead 
> of current process.

I don't think the risks which come with accepting DCOs are justified
in GDB at least.  The number of one-off contributors to GDB is
basically zero.

Re: DCO: Was: Re: Contributing to gdb

[Guinevere Larsen via Gdb]

On 6/17/24 1:32 PM, Eli Zaretskii wrote:
>> Date: Mon, 17 Jun 2024 12:57:41 -0300
>> Cc: GDB Development <gdb@sourceware.org>, binutils <binutils@sourceware.org>
>> From: Guinevere Larsen via Gdb <gdb@sourceware.org>
>>
>> On 6/17/24 12:00 PM, Andrew Pinski wrote:
>>> On Mon, Jun 17, 2024 at 5:23 AM Guinevere Larsen via Gdb
>>> <gdb@sourceware.org> wrote:
>>>> Just a heads up, too, if your patch isn't a trivial fix, you might need
>>>> to sign a bit of paperwork giving the copyright of changes to GDB to the
>>>> Free Software Foundation before we are able to accept the changes. I
>>>> mention this up front because I know a few people who were turned off by
>>>> the idea, even though the process itself isn't complicated.
>>> I just noticed that GDB (and binutils) are currently not accepting
>>> DCO's like both glibc
>>> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
>>> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
>>> Has there been any talk about accepting DCOs for gdb and binutils? Or
>>> has this not been brought up yet?
>> I haven't heard of it yet, every time I see a new contributor with a
>> patch accepted, the copyright assignment is always the way everyone
>> uses, and it has stalled the last release.
>>
>> I for one would absolutely love if we could use a quick DCO line instead
>> of current process.
> I don't think the risks which come with accepting DCOs are justified
> in GDB at least.  The number of one-off contributors to GDB is
> basically zero.
>
I know of 2 people who decided to not contribute to GDB as soon as I 
mentioned that there was a copyright process.

I also know of one person who I know was be a one off contributor 
(strager, who made a contribution just to make a video on how easy it is 
to contribute to open source projects). And saying we don't have them is 
a chicken and egg problem to me... could it be that we don't have them 
specifically because the process is so hostile to this type of contribution?

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii via Gdb]

> Date: Mon, 17 Jun 2024 13:37:56 -0300
> Cc: pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
> From: Guinevere Larsen <blarsen@redhat.com>
> 
> On 6/17/24 1:32 PM, Eli Zaretskii wrote:
> > I don't think the risks which come with accepting DCOs are justified
> > in GDB at least.  The number of one-off contributors to GDB is
> > basically zero.
> >
> I know of 2 people who decided to not contribute to GDB as soon as I 
> mentioned that there was a copyright process.

And with DCOs they were ready to contribute?

And who talked to them and made sure they understand completely what
copyright assignment means and entails?  IME, a large number of people
have completely distorted idea about that, and are mightily surprised
when told the facts by someone who knows them.

> And saying we don't have them is a chicken and egg problem to
> me... could it be that we don't have them specifically because the
> process is so hostile to this type of contribution?

This goes both ways, you know.

In contrast to the above, which may or may not be true, the risks
associated with accepting DCOs are real, not imaginary and not
"maybe".

Anyway, I don't see a need to argue.  You have expressed your opinion,
and I expressed mine.  We disagree.  It's allowed and is perfectly
okay.

Re: DCO: Was: Re: Contributing to gdb

[Guinevere Larsen via Gdb]

On 6/17/24 1:45 PM, Eli Zaretskii wrote:
>> Date: Mon, 17 Jun 2024 13:37:56 -0300
>> Cc: pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
>> From: Guinevere Larsen <blarsen@redhat.com>
>>
>> On 6/17/24 1:32 PM, Eli Zaretskii wrote:
>>> I don't think the risks which come with accepting DCOs are justified
>>> in GDB at least.  The number of one-off contributors to GDB is
>>> basically zero.
>>>
>> I know of 2 people who decided to not contribute to GDB as soon as I
>> mentioned that there was a copyright process.
> And with DCOs they were ready to contribute?

Yes. What they didn't want is to do is review an actual legal contract 
and sign it, even before knowing you need to give personal information 
that I am personally uncomfortable giving over the internet to an 
unknown person for a hobby project.

If I am ever not working for someone who has a blanket copyright 
assignment, I'll likely stop contributing code based on that. (I don't 
mean it as a threat since, as things stand, I plan on continuing to work 
professionally on GDB indefinitely, it is just a relevant fact for this 
conversation).

>
> And who talked to them and made sure they understand completely what
> copyright assignment means and entails?  IME, a large number of people
> have completely distorted idea about that, and are mightily surprised
> when told the facts by someone who knows them.
Another problem with this system, then, is scalability. Yes, we don't 
have huge swaths of people eagerly waiting to contribute to GDB, but if 
it is hard enough for regular contributors to find time to review 
patches, where is the time for someone who understands completely the 
copyright assignment to mentor prospective contributors before they are 
turned away when they read that this is a requirement in the 
contribution checklist?
>
>> And saying we don't have them is a chicken and egg problem to
>> me... could it be that we don't have them specifically because the
>> process is so hostile to this type of contribution?
> This goes both ways, you know.
>
> In contrast to the above, which may or may not be true, the risks
> associated with accepting DCOs are real, not imaginary and not
> "maybe".
Could you explain the risks? Not only I am not a lawyer, I have an extra 
large blindspot with regards to copyright law.
>
> Anyway, I don't see a need to argue.  You have expressed your opinion,
> and I expressed mine.  We disagree.  It's allowed and is perfectly
> okay.
>
I would like to change the current system, but I don't have all the 
information, so I think it would be beneficial for us to discuss this so 
that we don't rely on any one person's personal preference, and instead 
choose what is best for the project.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

Re: DCO: Was: Re: Contributing to gdb

[Andrew Pinski via Gdb]

On Mon, Jun 17, 2024 at 11:18 AM Guinevere Larsen <blarsen@redhat.com> wrote:
>
> On 6/17/24 1:45 PM, Eli Zaretskii wrote:
> >> Date: Mon, 17 Jun 2024 13:37:56 -0300
> >> Cc: pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
> >> From: Guinevere Larsen <blarsen@redhat.com>
> >>
> >> On 6/17/24 1:32 PM, Eli Zaretskii wrote:
> >>> I don't think the risks which come with accepting DCOs are justified
> >>> in GDB at least.  The number of one-off contributors to GDB is
> >>> basically zero.
> >>>
> >> I know of 2 people who decided to not contribute to GDB as soon as I
> >> mentioned that there was a copyright process.
> > And with DCOs they were ready to contribute?
>
> Yes. What they didn't want is to do is review an actual legal contract
> and sign it, even before knowing you need to give personal information
> that I am personally uncomfortable giving over the internet to an
> unknown person for a hobby project.
>
> If I am ever not working for someone who has a blanket copyright
> assignment, I'll likely stop contributing code based on that. (I don't
> mean it as a threat since, as things stand, I plan on continuing to work
> professionally on GDB indefinitely, it is just a relevant fact for this
> conversation).

The main reason why I brought this up because I know in the near
future (within a year) I will be wanting to help improve/implementing
GDB for aarch64 windows and currently my employer (Qualcomm) does not
have a blanket copyright right assignment and has been ok with the DCO
for submitting patches for GCC and glibc. So this will definitely get
in the way for me here.

Thanks,
Andrew Pinski

>
> >
> > And who talked to them and made sure they understand completely what
> > copyright assignment means and entails?  IME, a large number of people
> > have completely distorted idea about that, and are mightily surprised
> > when told the facts by someone who knows them.
> Another problem with this system, then, is scalability. Yes, we don't
> have huge swaths of people eagerly waiting to contribute to GDB, but if
> it is hard enough for regular contributors to find time to review
> patches, where is the time for someone who understands completely the
> copyright assignment to mentor prospective contributors before they are
> turned away when they read that this is a requirement in the
> contribution checklist?
> >
> >> And saying we don't have them is a chicken and egg problem to
> >> me... could it be that we don't have them specifically because the
> >> process is so hostile to this type of contribution?
> > This goes both ways, you know.
> >
> > In contrast to the above, which may or may not be true, the risks
> > associated with accepting DCOs are real, not imaginary and not
> > "maybe".
> Could you explain the risks? Not only I am not a lawyer, I have an extra
> large blindspot with regards to copyright law.
> >
> > Anyway, I don't see a need to argue.  You have expressed your opinion,
> > and I expressed mine.  We disagree.  It's allowed and is perfectly
> > okay.
> >
> I would like to change the current system, but I don't have all the
> information, so I think it would be beneficial for us to discuss this so
> that we don't rely on any one person's personal preference, and instead
> choose what is best for the project.
>
> --
> Cheers,
> Guinevere Larsen
> She/Her/Hers
>

Re: DCO: Was: Re: Contributing to gdb

[Arsen Arsenović via Gdb]

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

Guinevere Larsen <blarsen@redhat.com> writes:

> I know of 2 people who decided to not contribute to GDB as soon as I mentioned
> that there was a copyright process.
>
> I also know of one person who I know was be a one off contributor (strager, who
> made a contribution just to make a video on how easy it is to contribute to
> open source projects). And saying we don't have them is a chicken and egg
> problem to me... could it be that we don't have them specifically because the
> process is so hostile to this type of contribution?

I know some people who refuse to contribute due to this also.  Many
don't trust the FSF, many don't want to reveal information, many do not
see the difference between the FSF copyright process and a CLA (except
that the latter is often easier to process..).

I understand there are good reasons for copyright assignment to the FSF,
but the FSF seems to be considered less trustworthy nowadays, and this
is reflected in the likelihood of (even relatively experienced!) free
software contributors signing over copyright.

I've, for a long time, avoided contributing to projects with 'legal
routine' requirements (DCO included) due to the implications of sharing
real names.

(NOTE: I have copyright assignments on file and might file more
 ahead-of-time to avoid sinking time every time I contribute to a new
 project.  It has not stopped me, but it /has/ others.  I can completely
 understand those people also)
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii via Gdb]

> Date: Mon, 17 Jun 2024 15:18:25 -0300
> Cc: pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
> From: Guinevere Larsen <blarsen@redhat.com>
> 
> > And who talked to them and made sure they understand completely what
> > copyright assignment means and entails?  IME, a large number of people
> > have completely distorted idea about that, and are mightily surprised
> > when told the facts by someone who knows them.
> Another problem with this system, then, is scalability. Yes, we don't 
> have huge swaths of people eagerly waiting to contribute to GDB, but if 
> it is hard enough for regular contributors to find time to review 
> patches, where is the time for someone who understands completely the 
> copyright assignment to mentor prospective contributors before they are 
> turned away when they read that this is a requirement in the 
> contribution checklist?

That's not an excuse.  And you can ask me to do that.  I will make
time for it, exactly as I make time to review documentation patches
here, and as I make time to explain this stuff to contributors to
Emacs.

> > In contrast to the above, which may or may not be true, the risks
> > associated with accepting DCOs are real, not imaginary and not
> > "maybe".

> Could you explain the risks? Not only I am not a lawyer, I have an extra 
> large blindspot with regards to copyright law.

They were explained many times on gnu-prog-discuss 3 years ago, so you
are invited to read those discussions.  Basically people misrepresent
themselves as having the rights to contribute code which they have no
legal rights to contribute, and it's likely to happen exactly in the
cases in which the copyright assignment is complicated by the need to
obtain the disclaimer of the employer.

> > Anyway, I don't see a need to argue.  You have expressed your opinion,
> > and I expressed mine.  We disagree.  It's allowed and is perfectly
> > okay.
> >
> I would like to change the current system, but I don't have all the 
> information, so I think it would be beneficial for us to discuss this so 
> that we don't rely on any one person's personal preference, and instead 
> choose what is best for the project.

Anyone who wants to discuss this seriously should first read the
gnu-prog-discuss discussion of these issues, from June 2021 (it went
on all the way through July).

Re: DCO: Was: Re: Contributing to gdb

[Guinevere Larsen via Gdb]

On 6/17/24 4:37 PM, Eli Zaretskii wrote:
>> Date: Mon, 17 Jun 2024 15:18:25 -0300
>> Cc: pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
>> From: Guinevere Larsen <blarsen@redhat.com>
>>
>>> And who talked to them and made sure they understand completely what
>>> copyright assignment means and entails?  IME, a large number of people
>>> have completely distorted idea about that, and are mightily surprised
>>> when told the facts by someone who knows them.
>> Another problem with this system, then, is scalability. Yes, we don't
>> have huge swaths of people eagerly waiting to contribute to GDB, but if
>> it is hard enough for regular contributors to find time to review
>> patches, where is the time for someone who understands completely the
>> copyright assignment to mentor prospective contributors before they are
>> turned away when they read that this is a requirement in the
>> contribution checklist?
> That's not an excuse.  And you can ask me to do that.  I will make
> time for it, exactly as I make time to review documentation patches
> here, and as I make time to explain this stuff to contributors to
> Emacs.

Then I suggest you add your name and email to the wiki, where the people 
that never even get to the point of interacting with us will find it to 
ask for questions.

https://sourceware.org/gdb/wiki/ContributionChecklist#FSF_copyright_Assignment

>
>>> In contrast to the above, which may or may not be true, the risks
>>> associated with accepting DCOs are real, not imaginary and not
>>> "maybe".
>> Could you explain the risks? Not only I am not a lawyer, I have an extra
>> large blindspot with regards to copyright law.
> They were explained many times on gnu-prog-discuss 3 years ago, so you
> are invited to read those discussions.  Basically people misrepresent
> themselves as having the rights to contribute code which they have no
> legal rights to contribute, and it's likely to happen exactly in the
> cases in which the copyright assignment is complicated by the need to
> obtain the disclaimer of the employer.
>
>>> Anyway, I don't see a need to argue.  You have expressed your opinion,
>>> and I expressed mine.  We disagree.  It's allowed and is perfectly
>>> okay.
>>>
>> I would like to change the current system, but I don't have all the
>> information, so I think it would be beneficial for us to discuss this so
>> that we don't rely on any one person's personal preference, and instead
>> choose what is best for the project.
> Anyone who wants to discuss this seriously should first read the
> gnu-prog-discuss discussion of these issues, from June 2021 (it went
> on all the way through July).
>
Telling someone who actively asked to learn more that "ok, go read those 
email threads" without any convenience like saying the subject to search 
for it easily, or the archive where I can look for it, and furthermore, 
I am forced to subscribe to a list I frankly do not care about just to 
see the discussion you consider required reading before even accepting 
to have a conversation is a very unhelpful way to explain anything for 
anyone.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii via Gdb]

> From: Andrew Pinski <pinskia@gmail.com>
> Date: Mon, 17 Jun 2024 11:24:03 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.org, binutils@sourceware.org
> 
> The main reason why I brought this up because I know in the near
> future (within a year) I will be wanting to help improve/implementing
> GDB for aarch64 windows and currently my employer (Qualcomm) does not
> have a blanket copyright right assignment and has been ok with the DCO
> for submitting patches for GCC and glibc. So this will definitely get
> in the way for me here.

You should talk to the FSF lawyers, because I'm not sure you can
contribute based on a DCO in that case.  Your employer can claim they
have the legal rights for the code you wrote.

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii via Gdb]

> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: Eli Zaretskii <eliz@gnu.org>,  pinskia@gmail.com,  gdb@sourceware.org,
>   binutils@sourceware.org
> Date: Mon, 17 Jun 2024 21:15:58 +0200
> 
> I know some people who refuse to contribute due to this also.

That's not necessarily relevant.  We are interested in potential
contributors to GDB, who have either some code to contribute or some
practical ideas for such code, not just some people out there.

> Many don't trust the FSF, many don't want to reveal information,
> many do not see the difference between the FSF copyright process and
> a CLA (except that the latter is often easier to process..).

In general, yes, some (not many!) do.  But IME with maintaining Emacs,
I have yet to bump into a person who has code to contribute and whom I
couldn't convince that the copyright assignment is not a problem (if
they even thought that to begin with).

> I understand there are good reasons for copyright assignment to the FSF,
> but the FSF seems to be considered less trustworthy nowadays, and this
> is reflected in the likelihood of (even relatively experienced!) free
> software contributors signing over copyright.

Again, not IME.

> I've, for a long time, avoided contributing to projects with 'legal
> routine' requirements (DCO included) due to the implications of sharing
> real names.

There's no need to share a real name.  The assignments on file have
quite a few names that are withheld, with only a pseudonym on file.
This is a non-issue, for all practical purposes.  And, as you point
out, using DCOs doesn't change this aspect in any way.

> (NOTE: I have copyright assignments on file and might file more
>  ahead-of-time to avoid sinking time every time I contribute to a new
>  project.  It has not stopped me, but it /has/ others.  I can completely
>  understand those people also)

I understand them also.  I'm just saying that we should patiently
explain them the facts about the assignment's meaning and practices,
and IME that has an almost 100% success rate.

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii via Gdb]

> Date: Mon, 17 Jun 2024 16:48:13 -0300
> Cc: pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
> From: Guinevere Larsen <blarsen@redhat.com>
> 
> On 6/17/24 4:37 PM, Eli Zaretskii wrote:
> > That's not an excuse.  And you can ask me to do that.  I will make
> > time for it, exactly as I make time to review documentation patches
> > here, and as I make time to explain this stuff to contributors to
> > Emacs.
> 
> Then I suggest you add your name and email to the wiki, where the people 
> that never even get to the point of interacting with us will find it to 
> ask for questions.
> 
> https://sourceware.org/gdb/wiki/ContributionChecklist#FSF_copyright_Assignment

I don't mind, but I didn't see any names and emails mentioned there.
Did I miss something?

> > Anyone who wants to discuss this seriously should first read the
> > gnu-prog-discuss discussion of these issues, from June 2021 (it went
> > on all the way through July).
> >
> Telling someone who actively asked to learn more that "ok, go read those 
> email threads" without any convenience like saying the subject to search 
> for it easily, or the archive where I can look for it, and furthermore, 
> I am forced to subscribe to a list I frankly do not care about just to 
> see the discussion you consider required reading before even accepting 
> to have a conversation is a very unhelpful way to explain anything for 
> anyone.

This must be some grave misunderstanding.  The discussion to which I
pointed was a very long one, took more than a month, and expecting me
(or someone else) to summarize it is unreasonable, even if you ignore
the possibility that a summary might omit aspects that are important
for you, let alone the time required to produce such a summary.  The
gnu-prog-discuss list had a very small number of threads in June 2021,
so I thought finding the right one would be a no-brainer.  But since
it sounds like I was mistaken, I apologize; here's the link to the
beginning of that thread:

  https://lists.gnu.org/mailman/private/gnu-prog-discuss/2021q2/016757.html

The subject of the thread is, unsurprisingly, "Copyright assignments".
It also points to related discussions on GCC, glibc, and Gnulib lists.

The reason I think a serious discussion of this should start by
reading that one is that it doesn't sound a good investment of
everyone's time to re-iterate all the arguments which were already
brought forward there and discussed from every possible aspect.  I
apologize for not making myself clear earlier, and hope I made myself
more clear now: there was no intent to be unhelpful, just an attempt
to be efficient by pointing to a very extensive discussion of this and
related topics.

Re: DCO: Was: Re: Contributing to gdb

[Michael Matz via Gdb]

Hello,

On Mon, 17 Jun 2024, Andrew Pinski wrote:

> I just noticed that GDB (and binutils) are currently not accepting
> DCO's like both glibc
> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.

That is incorrect for binutils.  DCO contributions are accepted, as stated 
in binutils/MAINTAINERS.  (Discussed during some past Cauldron)


Ciao,
Michael.

Re: Contributing to gdb

[shaunak saha via Gdb]

Hi,

>>Hello! Welcome welcome, we always love to have new contributors :)

Thanks a lot for the warm welcome.

>>For watchpoints, the first bug that that page mentions is still open,
>>but apparently the last mention of anything related to it was in 2014
>>(the 2024 comment is unrelated), so you could first check if you can
>>still reproduce the issue, and maybe try to fix or close the bug if it
>>can't be reproduced anymore. I'm also a big fan of improving user
>>experience, so the second thing about watchpoints (and the misuse of the
>>word scope) is something I'd love to see, if you're interested in fixing it.

Sure, I will check as this will help me to get used to the gdb
development environment also better. Just to confirm, Is this the bug
you mentioned? "https://sourceware.org/bugzilla/show_bug.cgi?id=10645"

>>And for internals, if I may do a bit of promotion of my favorite area,
>>right now reverse debugging has a big problem: We rely on recording the
>>execution history of the inferior in a global variable, which is totally
>>not feasible if someone wants to record multiple inferiors at once. I'd
>>love to see a rework of this area that makes the history specific to an
>>inferior instead of relying on a global var. This could be pretty
>>complicated, as I don't exactly know how someone would go about doing
>>this and it might touch a couple different subsystems, but if you'd like
>>your first contribution to be tough as nails, I know I would love to see
>>it :)
Actually this is one of the areas I am very interested in too. This
would be a really good learning experience for me. For the rework of
the global variable issues can you please point me to the bug if it's
there. I can start by learning more about it.

>>If you want some help understanding some bits of GDB, feel free to reach
>>out on IRC (#gdb on libera chat), and if you feel shy about asking
>>questions in public, feel free to reach to me privately :) (though I
>>mostly only answer on work hours for Brazil).

Thanks a lot. I will reach out on IRC or ask you over email for my doubts.

>>Just a heads up, too, if your patch isn't a trivial fix, you might need
>>to sign a bit of paperwork giving the copyright of changes to GDB to the
>>Free Software Foundation before we are able to accept the changes. I
>>mention this up front because I know a few people who were turned off by
>>the idea, even though the process itself isn't complicated.

I understand. I am ok with signing the paperwork with FSF. I am
guessing that would not be a problem with my employer but I will still
check.

Regards,
Shaunak

On Mon, Jun 17, 2024 at 5:22 AM Guinevere Larsen <blarsen@redhat.com> wrote:
>
> On 6/14/24 6:52 PM, shaunak saha via Gdb wrote:
> > Hi all,
> >
> > I am new to the community and I'd like to contribute to gdb. I have 15
> > years of development experience in C mainly working in embedded
> > domain. Went through the project ideas page
> > "https://sourceware.org/gdb/wiki/ProjectIdeas". I would be interested
> > to contribute in areas like Embedded Debugging, watchpoints or
> > internals. Any suggestion would be great.
> >
> > Regards,
> > Shaunak
> >
> Hello! Welcome welcome, we always love to have new contributors :)
>
> My first thought with regards to that page is that I don't know how up
> to date it is... the last update seems to be back in 2021, which is from
> before I joined the project. That said, I think there is plenty of
> things to do in the areas you mentioned.
>
> For embedded debugging, unfortunately I have no idea what the situation is.
>
> For watchpoints, the first bug that that page mentions is still open,
> but apparently the last mention of anything related to it was in 2014
> (the 2024 comment is unrelated), so you could first check if you can
> still reproduce the issue, and maybe try to fix or close the bug if it
> can't be reproduced anymore. I'm also a big fan of improving user
> experience, so the second thing about watchpoints (and the misuse of the
> word scope) is something I'd love to see, if you're interested in fixing it.
>
> And for internals, if I may do a bit of promotion of my favorite area,
> right now reverse debugging has a big problem: We rely on recording the
> execution history of the inferior in a global variable, which is totally
> not feasible if someone wants to record multiple inferiors at once. I'd
> love to see a rework of this area that makes the history specific to an
> inferior instead of relying on a global var. This could be pretty
> complicated, as I don't exactly know how someone would go about doing
> this and it might touch a couple different subsystems, but if you'd like
> your first contribution to be tough as nails, I know I would love to see
> it :)
>
>
> Once you decided on something to work on, if it isn't something that
> feels obvious to you or feels like it could depend on some design
> decisions, I recommend sending a very simple prototype as an RFC to the
> gdb-patches@sourceware list, so people can discuss if your approach
> makes sense.
>
> If you want some help understanding some bits of GDB, feel free to reach
> out on IRC (#gdb on libera chat), and if you feel shy about asking
> questions in public, feel free to reach to me privately :) (though I
> mostly only answer on work hours for Brazil).
>
>
> Just a heads up, too, if your patch isn't a trivial fix, you might need
> to sign a bit of paperwork giving the copyright of changes to GDB to the
> Free Software Foundation before we are able to accept the changes. I
> mention this up front because I know a few people who were turned off by
> the idea, even though the process itself isn't complicated.
>
> --
> Cheers,
> Guinevere Larsen
> She/Her/Hers
>

Re: Contributing to gdb

[Guinevere Larsen via Gdb]

On 6/19/24 4:38 AM, shaunak saha wrote:
> Hi,
>
>>> Hello! Welcome welcome, we always love to have new contributors :)
> Thanks a lot for the warm welcome.
>
>>> For watchpoints, the first bug that that page mentions is still open,
>>> but apparently the last mention of anything related to it was in 2014
>>> (the 2024 comment is unrelated), so you could first check if you can
>>> still reproduce the issue, and maybe try to fix or close the bug if it
>>> can't be reproduced anymore. I'm also a big fan of improving user
>>> experience, so the second thing about watchpoints (and the misuse of the
>>> word scope) is something I'd love to see, if you're interested in fixing it.
> Sure, I will check as this will help me to get used to the gdb
> development environment also better. Just to confirm, Is this the bug
> you mentioned? "https://sourceware.org/bugzilla/show_bug.cgi?id=10645"
Yes, this was the bug I was thinking of.
>
>>> And for internals, if I may do a bit of promotion of my favorite area,
>>> right now reverse debugging has a big problem: We rely on recording the
>>> execution history of the inferior in a global variable, which is totally
>>> not feasible if someone wants to record multiple inferiors at once. I'd
>>> love to see a rework of this area that makes the history specific to an
>>> inferior instead of relying on a global var. This could be pretty
>>> complicated, as I don't exactly know how someone would go about doing
>>> this and it might touch a couple different subsystems, but if you'd like
>>> your first contribution to be tough as nails, I know I would love to see
>>> it :)
> Actually this is one of the areas I am very interested in too. This
> would be a really good learning experience for me. For the rework of
> the global variable issues can you please point me to the bug if it's
> there. I can start by learning more about it.

There wasn't a bug yet, but I just created one 
https://sourceware.org/bugzilla/show_bug.cgi?id=31911

I tried to add my thoughts on how this could be done, but this was 
thought in the moment, no real research into what's possible or 
reasonable. I just so happened to  be working close to this area and had 
many unstructured thoughts hahaha

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

>
>>> If you want some help understanding some bits of GDB, feel free to reach
>>> out on IRC (#gdb on libera chat), and if you feel shy about asking
>>> questions in public, feel free to reach to me privately :) (though I
>>> mostly only answer on work hours for Brazil).
> Thanks a lot. I will reach out on IRC or ask you over email for my doubts.
>
>>> Just a heads up, too, if your patch isn't a trivial fix, you might need
>>> to sign a bit of paperwork giving the copyright of changes to GDB to the
>>> Free Software Foundation before we are able to accept the changes. I
>>> mention this up front because I know a few people who were turned off by
>>> the idea, even though the process itself isn't complicated.
> I understand. I am ok with signing the paperwork with FSF. I am
> guessing that would not be a problem with my employer but I will still
> check.
>
> Regards,
> Shaunak
>
> On Mon, Jun 17, 2024 at 5:22 AM Guinevere Larsen <blarsen@redhat.com> wrote:
>> On 6/14/24 6:52 PM, shaunak saha via Gdb wrote:
>>> Hi all,
>>>
>>> I am new to the community and I'd like to contribute to gdb. I have 15
>>> years of development experience in C mainly working in embedded
>>> domain. Went through the project ideas page
>>> "https://sourceware.org/gdb/wiki/ProjectIdeas". I would be interested
>>> to contribute in areas like Embedded Debugging, watchpoints or
>>> internals. Any suggestion would be great.
>>>
>>> Regards,
>>> Shaunak
>>>
>> Hello! Welcome welcome, we always love to have new contributors :)
>>
>> My first thought with regards to that page is that I don't know how up
>> to date it is... the last update seems to be back in 2021, which is from
>> before I joined the project. That said, I think there is plenty of
>> things to do in the areas you mentioned.
>>
>> For embedded debugging, unfortunately I have no idea what the situation is.
>>
>> For watchpoints, the first bug that that page mentions is still open,
>> but apparently the last mention of anything related to it was in 2014
>> (the 2024 comment is unrelated), so you could first check if you can
>> still reproduce the issue, and maybe try to fix or close the bug if it
>> can't be reproduced anymore. I'm also a big fan of improving user
>> experience, so the second thing about watchpoints (and the misuse of the
>> word scope) is something I'd love to see, if you're interested in fixing it.
>>
>> And for internals, if I may do a bit of promotion of my favorite area,
>> right now reverse debugging has a big problem: We rely on recording the
>> execution history of the inferior in a global variable, which is totally
>> not feasible if someone wants to record multiple inferiors at once. I'd
>> love to see a rework of this area that makes the history specific to an
>> inferior instead of relying on a global var. This could be pretty
>> complicated, as I don't exactly know how someone would go about doing
>> this and it might touch a couple different subsystems, but if you'd like
>> your first contribution to be tough as nails, I know I would love to see
>> it :)
>>
>>
>> Once you decided on something to work on, if it isn't something that
>> feels obvious to you or feels like it could depend on some design
>> decisions, I recommend sending a very simple prototype as an RFC to the
>> gdb-patches@sourceware list, so people can discuss if your approach
>> makes sense.
>>
>> If you want some help understanding some bits of GDB, feel free to reach
>> out on IRC (#gdb on libera chat), and if you feel shy about asking
>> questions in public, feel free to reach to me privately :) (though I
>> mostly only answer on work hours for Brazil).
>>
>>
>> Just a heads up, too, if your patch isn't a trivial fix, you might need
>> to sign a bit of paperwork giving the copyright of changes to GDB to the
>> Free Software Foundation before we are able to accept the changes. I
>> mention this up front because I know a few people who were turned off by
>> the idea, even though the process itself isn't complicated.
>>
>> --
>> Cheers,
>> Guinevere Larsen
>> She/Her/Hers
>>

Re: DCO: Was: Re: Contributing to gdb

[Nick Clifton via Gdb]

Hi Gwen, Hi Andrew,
>> I just noticed that GDB (and binutils) are currently not accepting
>> DCO's like both glibc

The GNU Binutils *does* accept contributions signed with a DCO:

   https://sourceware.org/binutils/wiki/HowToContribute

This change has been in place since October 2022.

Cheers
   Nick

Re: DCO: Was: Re: Contributing to gdb

[Tom Tromey]

>> I just noticed that GDB (and binutils) are currently not accepting
>> DCO's like both glibc
>> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
>> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
>> Has there been any talk about accepting DCOs for gdb and binutils? Or
>> has this not been brought up yet?

If gcc, glibc, and binutils accept it, then IMO gdb should as well.

Tom

Re: Contributing to gdb

[shaunak saha via Gdb]

Hi Guinevere,

Thanks for confirming. I checked the bug 10645 in an x86 system. I don't
see the issue anymore:

Continuing.
[infrun] clear_proceed_status_thread: 17395.17395.0
[infrun] proceed: enter
  [infrun] follow_fork: enter
  [infrun] follow_fork: exit
  [infrun] proceed: cur_thr = 17395.17395.0
  [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT,
resume_ptid=17395.0.0
  [infrun] scoped_disable_commit_resumed: reason=proceeding
  [infrun] start_step_over: enter
    [infrun] start_step_over: stealing global queue of threads to step,
length = 0
    [infrun] operator(): step-over queue now empty
  [infrun] start_step_over: exit
  [infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop
    [infrun] proceed_resume_thread_checked: resuming 17395.17395.0
    [infrun] resume_1:* step=0*, signal=GDB_SIGNAL_0, trap_expected=0,
current thread [17395.17395.0] at 0x55555555514b
    [infrun] do_target_resume: resume_ptid=17395.17395.0, step=0,
sig=GDB_SIGNAL_0
  [infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop
  [infrun] reset: reason=proceeding

I can see the step is 0.

>https://sourceware.org/bugzilla/show_bug.cgi?id=31911
Thanks for creating the bug. I am looking into it and trying to understand
the code.

Regards,
Shaunak




On Wed, Jun 19, 2024 at 5:07 AM Guinevere Larsen <blarsen@redhat.com> wrote:

> On 6/19/24 4:38 AM, shaunak saha wrote:
> > Hi,
> >
> >>> Hello! Welcome welcome, we always love to have new contributors :)
> > Thanks a lot for the warm welcome.
> >
> >>> For watchpoints, the first bug that that page mentions is still open,
> >>> but apparently the last mention of anything related to it was in 2014
> >>> (the 2024 comment is unrelated), so you could first check if you can
> >>> still reproduce the issue, and maybe try to fix or close the bug if it
> >>> can't be reproduced anymore. I'm also a big fan of improving user
> >>> experience, so the second thing about watchpoints (and the misuse of
> the
> >>> word scope) is something I'd love to see, if you're interested in
> fixing it.
> > Sure, I will check as this will help me to get used to the gdb
> > development environment also better. Just to confirm, Is this the bug
> > you mentioned? "https://sourceware.org/bugzilla/show_bug.cgi?id=10645"
> Yes, this was the bug I was thinking of.
> >
> >>> And for internals, if I may do a bit of promotion of my favorite area,
> >>> right now reverse debugging has a big problem: We rely on recording the
> >>> execution history of the inferior in a global variable, which is
> totally
> >>> not feasible if someone wants to record multiple inferiors at once. I'd
> >>> love to see a rework of this area that makes the history specific to an
> >>> inferior instead of relying on a global var. This could be pretty
> >>> complicated, as I don't exactly know how someone would go about doing
> >>> this and it might touch a couple different subsystems, but if you'd
> like
> >>> your first contribution to be tough as nails, I know I would love to
> see
> >>> it :)
> > Actually this is one of the areas I am very interested in too. This
> > would be a really good learning experience for me. For the rework of
> > the global variable issues can you please point me to the bug if it's
> > there. I can start by learning more about it.
>
> There wasn't a bug yet, but I just created one
> https://sourceware.org/bugzilla/show_bug.cgi?id=31911
>
> I tried to add my thoughts on how this could be done, but this was
> thought in the moment, no real research into what's possible or
> reasonable. I just so happened to  be working close to this area and had
> many unstructured thoughts hahaha
>
> --
> Cheers,
> Guinevere Larsen
> She/Her/Hers
>
> >
> >>> If you want some help understanding some bits of GDB, feel free to
> reach
> >>> out on IRC (#gdb on libera chat), and if you feel shy about asking
> >>> questions in public, feel free to reach to me privately :) (though I
> >>> mostly only answer on work hours for Brazil).
> > Thanks a lot. I will reach out on IRC or ask you over email for my
> doubts.
> >
> >>> Just a heads up, too, if your patch isn't a trivial fix, you might need
> >>> to sign a bit of paperwork giving the copyright of changes to GDB to
> the
> >>> Free Software Foundation before we are able to accept the changes. I
> >>> mention this up front because I know a few people who were turned off
> by
> >>> the idea, even though the process itself isn't complicated.
> > I understand. I am ok with signing the paperwork with FSF. I am
> > guessing that would not be a problem with my employer but I will still
> > check.
> >
> > Regards,
> > Shaunak
> >
> > On Mon, Jun 17, 2024 at 5:22 AM Guinevere Larsen <blarsen@redhat.com>
> wrote:
> >> On 6/14/24 6:52 PM, shaunak saha via Gdb wrote:
> >>> Hi all,
> >>>
> >>> I am new to the community and I'd like to contribute to gdb. I have 15
> >>> years of development experience in C mainly working in embedded
> >>> domain. Went through the project ideas page
> >>> "https://sourceware.org/gdb/wiki/ProjectIdeas". I would be interested
> >>> to contribute in areas like Embedded Debugging, watchpoints or
> >>> internals. Any suggestion would be great.
> >>>
> >>> Regards,
> >>> Shaunak
> >>>
> >> Hello! Welcome welcome, we always love to have new contributors :)
> >>
> >> My first thought with regards to that page is that I don't know how up
> >> to date it is... the last update seems to be back in 2021, which is from
> >> before I joined the project. That said, I think there is plenty of
> >> things to do in the areas you mentioned.
> >>
> >> For embedded debugging, unfortunately I have no idea what the situation
> is.
> >>
> >> For watchpoints, the first bug that that page mentions is still open,
> >> but apparently the last mention of anything related to it was in 2014
> >> (the 2024 comment is unrelated), so you could first check if you can
> >> still reproduce the issue, and maybe try to fix or close the bug if it
> >> can't be reproduced anymore. I'm also a big fan of improving user
> >> experience, so the second thing about watchpoints (and the misuse of the
> >> word scope) is something I'd love to see, if you're interested in
> fixing it.
> >>
> >> And for internals, if I may do a bit of promotion of my favorite area,
> >> right now reverse debugging has a big problem: We rely on recording the
> >> execution history of the inferior in a global variable, which is totally
> >> not feasible if someone wants to record multiple inferiors at once. I'd
> >> love to see a rework of this area that makes the history specific to an
> >> inferior instead of relying on a global var. This could be pretty
> >> complicated, as I don't exactly know how someone would go about doing
> >> this and it might touch a couple different subsystems, but if you'd like
> >> your first contribution to be tough as nails, I know I would love to see
> >> it :)
> >>
> >>
> >> Once you decided on something to work on, if it isn't something that
> >> feels obvious to you or feels like it could depend on some design
> >> decisions, I recommend sending a very simple prototype as an RFC to the
> >> gdb-patches@sourceware list, so people can discuss if your approach
> >> makes sense.
> >>
> >> If you want some help understanding some bits of GDB, feel free to reach
> >> out on IRC (#gdb on libera chat), and if you feel shy about asking
> >> questions in public, feel free to reach to me privately :) (though I
> >> mostly only answer on work hours for Brazil).
> >>
> >>
> >> Just a heads up, too, if your patch isn't a trivial fix, you might need
> >> to sign a bit of paperwork giving the copyright of changes to GDB to the
> >> Free Software Foundation before we are able to accept the changes. I
> >> mention this up front because I know a few people who were turned off by
> >> the idea, even though the process itself isn't complicated.
> >>
> >> --
> >> Cheers,
> >> Guinevere Larsen
> >> She/Her/Hers
> >>
>
>

Re: Contributing to gdb

[Tom Tromey]

>>>>> "shaunak" == shaunak saha via Gdb <gdb@sourceware.org> writes:

shaunak> I am new to the community and I'd like to contribute to gdb. I have 15
shaunak> years of development experience in C mainly working in embedded
shaunak> domain. Went through the project ideas page
shaunak> "https://sourceware.org/gdb/wiki/ProjectIdeas". I would be interested
shaunak> to contribute in areas like Embedded Debugging, watchpoints or
shaunak> internals. Any suggestion would be great.

In addition to what Guinevere said, there's a good-first-bug keyword in
bugzilla.  These are bugs that are expected to not be too difficult and
can be a good starting point.

https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&f1=keywords&keywords=good-first-bug%2C%20&keywords_type=allwords&list_id=84360&product=gdb&query_format=advanced

Tom

Re: DCO: Was: Re: Contributing to gdb

[Thiago Jung Bauermann via Gdb]

Hello Eli,

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 17 Jun 2024 16:48:13 -0300
>> Cc: pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
>> From: Guinevere Larsen <blarsen@redhat.com>
>> 
> This must be some grave misunderstanding.  The discussion to which I
> pointed was a very long one, took more than a month, and expecting me
> (or someone else) to summarize it is unreasonable, even if you ignore
> the possibility that a summary might omit aspects that are important
> for you, let alone the time required to produce such a summary.  The
> gnu-prog-discuss list had a very small number of threads in June 2021,
> so I thought finding the right one would be a no-brainer.  But since
> it sounds like I was mistaken, I apologize; here's the link to the
> beginning of that thread:
>
>   https://lists.gnu.org/mailman/private/gnu-prog-discuss/2021q2/016757.html
>
> The subject of the thread is, unsurprisingly, "Copyright assignments".
> It also points to related discussions on GCC, glibc, and Gnulib lists.
>
> The reason I think a serious discussion of this should start by
> reading that one is that it doesn't sound a good investment of
> everyone's time to re-iterate all the arguments which were already
> brought forward there and discussed from every possible aspect.  I
> apologize for not making myself clear earlier, and hope I made myself
> more clear now: there was no intent to be unhelpful, just an attempt
> to be efficient by pointing to a very extensive discussion of this and
> related topics.

I'm interested in reading that thread and in the discussion of whether
GDB should accept contributions under the DCO. I don't have a personal
need for it, but my opinion is that it would be beneficial to the GDB
project.

Unfortunately I can't access that mailing list archive: it requires a
password. My understanding is that gnu-prog-discuss is only accessible
to GNU project maintainers.

Would it be possible to copy that mailing list thread to a publicly
accessible location?
-- 
Thiago

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii via Gdb]

> From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
> Cc: Guinevere Larsen <blarsen@redhat.com>,  pinskia@gmail.com,
>   gdb@sourceware.org,  binutils@sourceware.org
> Date: Thu, 27 Jun 2024 14:48:00 -0300
> 
> >   https://lists.gnu.org/mailman/private/gnu-prog-discuss/2021q2/016757.html
> >
> > The subject of the thread is, unsurprisingly, "Copyright assignments".
> > It also points to related discussions on GCC, glibc, and Gnulib lists.
> >
> > The reason I think a serious discussion of this should start by
> > reading that one is that it doesn't sound a good investment of
> > everyone's time to re-iterate all the arguments which were already
> > brought forward there and discussed from every possible aspect.  I
> > apologize for not making myself clear earlier, and hope I made myself
> > more clear now: there was no intent to be unhelpful, just an attempt
> > to be efficient by pointing to a very extensive discussion of this and
> > related topics.
> 
> I'm interested in reading that thread and in the discussion of whether
> GDB should accept contributions under the DCO. I don't have a personal
> need for it, but my opinion is that it would be beneficial to the GDB
> project.
> 
> Unfortunately I can't access that mailing list archive: it requires a
> password. My understanding is that gnu-prog-discuss is only accessible
> to GNU project maintainers.

I'm not sure this is true.  Did you try subscribing?

> Would it be possible to copy that mailing list thread to a publicly
> accessible location?

That's not for me to decide, please talk to the list admins.

Re: DCO: Was: Re: Contributing to gdb

[NightStrike via Gdb]

On Tue, Jun 18, 2024 at 7:55 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Arsen Arsenović <arsen@aarsen.me>
> > I've, for a long time, avoided contributing to projects with 'legal
> > routine' requirements (DCO included) due to the implications of sharing
> > real names.
>
> There's no need to share a real name.  The assignments on file have
> quite a few names that are withheld, with only a pseudonym on file.
> This is a non-issue, for all practical purposes.  And, as you point
> out, using DCOs doesn't change this aspect in any way.

Is this really true?  I was denied being able to work on GCC for this
reason (many years ago, before DCO), because I refused to reveal my
PII.  I pointed out that a real-sounding fake name is no better than a
fake-sounding fake name, which eventually led to someone (I think Ian)
explaining that sharing your name is only the first step in validating
someone's identity.  I never pursued it further.

Can you please explain how copyright assignments are validated if you
don't have to share your real name, as opposed to providing a
real-sounding fake name?  This one point has prevented my own
contributions since 2008; I've limited myself to simply running tests
and opening PR's.

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii via Gdb]

> From: NightStrike <nightstrike@gmail.com>
> Date: Thu, 27 Jun 2024 20:43:05 -0400
> Cc: Arsen Arsenović <arsen@aarsen.me>, blarsen@redhat.com, 
> 	pinskia@gmail.com, gdb@sourceware.org, binutils@sourceware.org
> 
> On Tue, Jun 18, 2024 at 7:55 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > > From: Arsen Arsenović <arsen@aarsen.me>
> > > I've, for a long time, avoided contributing to projects with 'legal
> > > routine' requirements (DCO included) due to the implications of sharing
> > > real names.
> >
> > There's no need to share a real name.  The assignments on file have
> > quite a few names that are withheld, with only a pseudonym on file.
> > This is a non-issue, for all practical purposes.  And, as you point
> > out, using DCOs doesn't change this aspect in any way.
> 
> Is this really true?  I was denied being able to work on GCC for this
> reason (many years ago, before DCO), because I refused to reveal my
> PII.  I pointed out that a real-sounding fake name is no better than a
> fake-sounding fake name, which eventually led to someone (I think Ian)
> explaining that sharing your name is only the first step in validating
> someone's identity.  I never pursued it further.

IME, it's true.  Like I said, I see in the assignments on file names
of people that are pseudonyms, with real names "withheld".

> Can you please explain how copyright assignments are validated if you
> don't have to share your real name, as opposed to providing a
> real-sounding fake name?  This one point has prevented my own
> contributions since 2008; I've limited myself to simply running tests
> and opening PR's.

If you are asking me from the POV of a maintainer of a GNU project
(Emacs), then whether the name is real or not doesn't bother me.  As
long as the assignment for "Some Name <some@email.address>" is on
file, I accept the contributions, no questions asked.

If you are asking me from the POV of the FSF copyright-assignment
clerk, the person who deals with the copyright-assignment process,
then I don't know how they do it.  I suggest to ask them.  They can be
reached at copyright-clerk@fsf.org.

Re: Contributing to gdb

[shaunak saha via Gdb]

Thanks Tom.

-Shaunak

On Wed, Jun 26, 2024 at 10:38 AM Tom Tromey <tom@tromey.com> wrote:

> >>>>> "shaunak" == shaunak saha via Gdb <gdb@sourceware.org> writes:
>
> shaunak> I am new to the community and I'd like to contribute to gdb. I
> have 15
> shaunak> years of development experience in C mainly working in embedded
> shaunak> domain. Went through the project ideas page
> shaunak> "https://sourceware.org/gdb/wiki/ProjectIdeas". I would be
> interested
> shaunak> to contribute in areas like Embedded Debugging, watchpoints or
> shaunak> internals. Any suggestion would be great.
>
> In addition to what Guinevere said, there's a good-first-bug keyword in
> bugzilla.  These are bugs that are expected to not be too difficult and
> can be a good starting point.
>
>
> https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&f1=keywords&keywords=good-first-bug%2C%20&keywords_type=allwords&list_id=84360&product=gdb&query_format=advanced
>
> Tom
>

Re: DCO: Was: Re: Contributing to gdb

[Thiago Jung Bauermann via Gdb]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
>> Cc: Guinevere Larsen <blarsen@redhat.com>,  pinskia@gmail.com,
>>   gdb@sourceware.org,  binutils@sourceware.org
>> Date: Thu, 27 Jun 2024 14:48:00 -0300
>> 
>> >   https://lists.gnu.org/mailman/private/gnu-prog-discuss/2021q2/016757.html
>> >
>> > The subject of the thread is, unsurprisingly, "Copyright assignments".
>> > It also points to related discussions on GCC, glibc, and Gnulib lists.
>> >
>> > The reason I think a serious discussion of this should start by
>> > reading that one is that it doesn't sound a good investment of
>> > everyone's time to re-iterate all the arguments which were already
>> > brought forward there and discussed from every possible aspect.  I
>> > apologize for not making myself clear earlier, and hope I made myself
>> > more clear now: there was no intent to be unhelpful, just an attempt
>> > to be efficient by pointing to a very extensive discussion of this and
>> > related topics.
>> 
>> I'm interested in reading that thread and in the discussion of whether
>> GDB should accept contributions under the DCO. I don't have a personal
>> need for it, but my opinion is that it would be beneficial to the GDB
>> project.
>> 
>> Unfortunately I can't access that mailing list archive: it requires a
>> password. My understanding is that gnu-prog-discuss is only accessible
>> to GNU project maintainers.
>
> I'm not sure this is true.  Did you try subscribing?

I did, and I was accepted. Thank you for the suggestion.
FWIW, I found this information about the mailing list¹:

  gnu-prog[+discuss] subscription requests?

  Membership in the gnu-prog and gnu-prog-discuss mailing lists is
  restricted to direct GNU contributors, and thus moderated.

  Question: Is there a recipe for knowing when to approve and when to
  discard subscription requests?

  Answer from Karl:

      If the person is in the fp:/gd/gnuorg/maintainers file,
          ok to approve.
      If the person has an account on fencepost,
          ok to approve.
      If the person is a member of GNU (not nongnu) package on Savannah,
          ok to approve.
      When in doubt, ask maintainers@gnu.org before approving.

>> Would it be possible to copy that mailing list thread to a publicly
>> accessible location?
>
> That's not for me to decide, please talk to the list admins.

Ok, I'll ask.
-- 
Thiago

¹ https://savannah.gnu.org/maintenance/MailingListNotes/

Re: DCO: Was: Re: Contributing to gdb

[Luis Machado via Gdb]

Hi,

On 6/23/24 23:06, Tom Tromey wrote:
>>> I just noticed that GDB (and binutils) are currently not accepting
>>> DCO's like both glibc
>>> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
>>> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
>>> Has there been any talk about accepting DCOs for gdb and binutils? Or
>>> has this not been brought up yet?
> 
> If gcc, glibc, and binutils accept it, then IMO gdb should as well.
> 
> Tom

Bumping this thread. I noticed there was a mention of aligning gcc/glibc/binutils in terms
of DCO text. That made me wonder where we stand regarding DCO for gdb [1], and if we really
want to stray from the other toolchain projects by not making a decision on whether we accept
it or not.

[1] https://inbox.sourceware.org/binutils/24b26a75-3b3d-4a00-af92-0b7c331e2db7@redhat.com/

Re: DCO: Was: Re: Contributing to gdb

[Andrew Burgess via Gdb]

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

> Hi,
>
> On 6/23/24 23:06, Tom Tromey wrote:
>>>> I just noticed that GDB (and binutils) are currently not accepting
>>>> DCO's like both glibc
>>>> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
>>>> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
>>>> Has there been any talk about accepting DCOs for gdb and binutils? Or
>>>> has this not been brought up yet?
>> 
>> If gcc, glibc, and binutils accept it, then IMO gdb should as well.
>> 
>> Tom
>
> Bumping this thread. I noticed there was a mention of aligning gcc/glibc/binutils in terms
> of DCO text. That made me wonder where we stand regarding DCO for gdb [1], and if we really
> want to stray from the other toolchain projects by not making a decision on whether we accept
> it or not.
>
> [1] https://inbox.sourceware.org/binutils/24b26a75-3b3d-4a00-af92-0b7c331e2db7@redhat.com/

Based on nothing more than remaining consistent with gcc, binutils, and
glibc, I think we should make the switch to accepting DCO contributions
under the same terms that binutils uses[2] (as well as accepting FSF
assigned contributions).

I'm volunteering myself to add suitable words to the GDB wiki (based off
the binutils wording), unless anyone objects.  Ideally I'd like a +1
from a couple of other global maintainers with no serious objections,
and I'll go ahead and make the change.

I think that Eli believes the concerns with FSF assignment are
overblown, and given the information provided, I'm inclined to agree.
But at this point, with other components accepting DCO, I'm not sure
that's really relevant.  Unless there's a super compelling reason why
GDB should diverge ... I think we should fall into line with the other
components.

[2] https://sourceware.org/binutils/wiki/HowToContribute

Thanks,
Andrew

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii via Gdb]

> From: Andrew Burgess <aburgess@redhat.com>
> Cc: Andrew Pinski <pinskia@gmail.com>, GDB Development <gdb@sourceware.org>,
>  Eli Zaretskii <eliz@gnu.org>
> Date: Mon, 13 Jan 2025 17:14:41 +0000
> 
> I think that Eli believes the concerns with FSF assignment are
> overblown, and given the information provided, I'm inclined to agree.
> But at this point, with other components accepting DCO, I'm not sure
> that's really relevant.  Unless there's a super compelling reason why
> GDB should diverge ... I think we should fall into line with the other
> components.

I mostly fear that by accepting DCOs we will open ourselves to
contributions from people who are not authorized to contribute their
code (e.g., it was copied from somewhere, or their employment contract
makes all their code the property of their employer, or something of
that nature).  DCO makes it much easier to submit code based on
incorrect understanding of what the DCO text says, so the probability
for honest mistakes is higher than with CA.

Re: DCO: Was: Re: Contributing to gdb

[Simon Marchi via Gdb]

On 2025-01-13 12:14, Andrew Burgess via Gdb wrote:
> Luis Machado via Gdb <gdb@sourceware.org> writes:
> 
>> Hi,
>>
>> On 6/23/24 23:06, Tom Tromey wrote:
>>>>> I just noticed that GDB (and binutils) are currently not accepting
>>>>> DCO's like both glibc
>>>>> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
>>>>> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
>>>>> Has there been any talk about accepting DCOs for gdb and binutils? Or
>>>>> has this not been brought up yet?
>>>
>>> If gcc, glibc, and binutils accept it, then IMO gdb should as well.
>>>
>>> Tom
>>
>> Bumping this thread. I noticed there was a mention of aligning gcc/glibc/binutils in terms
>> of DCO text. That made me wonder where we stand regarding DCO for gdb [1], and if we really
>> want to stray from the other toolchain projects by not making a decision on whether we accept
>> it or not.
>>
>> [1] https://inbox.sourceware.org/binutils/24b26a75-3b3d-4a00-af92-0b7c331e2db7@redhat.com/
> 
> Based on nothing more than remaining consistent with gcc, binutils, and
> glibc, I think we should make the switch to accepting DCO contributions
> under the same terms that binutils uses[2] (as well as accepting FSF
> assigned contributions).
> 
> I'm volunteering myself to add suitable words to the GDB wiki (based off
> the binutils wording), unless anyone objects.  Ideally I'd like a +1
> from a couple of other global maintainers with no serious objections,
> and I'll go ahead and make the change.
> 
> I think that Eli believes the concerns with FSF assignment are
> overblown, and given the information provided, I'm inclined to agree.
> But at this point, with other components accepting DCO, I'm not sure
> that's really relevant.  Unless there's a super compelling reason why
> GDB should diverge ... I think we should fall into line with the other
> components.

I would be happy if we accepted DCO contributions.  Having to go through
some copyright assignment paperwork is not the end of the world, but it
is one of many annoyances that add friction for new contributors (others
I think of right now are the use of mailing lists for reviews and our
specific coding style that we are unable to enforce with an automated
tool).

Simon

Re: DCO: Was: Re: Contributing to gdb

[Luis Machado via Gdb]

On 1/13/25 17:14, Andrew Burgess wrote:
> Luis Machado via Gdb <gdb@sourceware.org> writes:
> 
>> Hi,
>>
>> On 6/23/24 23:06, Tom Tromey wrote:
>>>>> I just noticed that GDB (and binutils) are currently not accepting
>>>>> DCO's like both glibc
>>>>> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
>>>>> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
>>>>> Has there been any talk about accepting DCOs for gdb and binutils? Or
>>>>> has this not been brought up yet?
>>>
>>> If gcc, glibc, and binutils accept it, then IMO gdb should as well.
>>>
>>> Tom
>>
>> Bumping this thread. I noticed there was a mention of aligning gcc/glibc/binutils in terms
>> of DCO text. That made me wonder where we stand regarding DCO for gdb [1], and if we really
>> want to stray from the other toolchain projects by not making a decision on whether we accept
>> it or not.
>>
>> [1] https://inbox.sourceware.org/binutils/24b26a75-3b3d-4a00-af92-0b7c331e2db7@redhat.com/
> 
> Based on nothing more than remaining consistent with gcc, binutils, and
> glibc, I think we should make the switch to accepting DCO contributions
> under the same terms that binutils uses[2] (as well as accepting FSF
> assigned contributions).
> 
> I'm volunteering myself to add suitable words to the GDB wiki (based off
> the binutils wording), unless anyone objects.  Ideally I'd like a +1
> from a couple of other global maintainers with no serious objections,
> and I'll go ahead and make the change.
> 
> I think that Eli believes the concerns with FSF assignment are
> overblown, and given the information provided, I'm inclined to agree.
> But at this point, with other components accepting DCO, I'm not sure
> that's really relevant.  Unless there's a super compelling reason why
> GDB should diverge ... I think we should fall into line with the other
> components.
> 
> [2] https://sourceware.org/binutils/wiki/HowToContribute
> 
> Thanks,
> Andrew
> 

I did some reading on DCO's and I have mixed feelings. I haven't followed
discussions about DCO's on the other GNU tools projects, so it is not clear
to me yet how/if they addressed the shortcomings of DCO's.

While I agree having gdb be the sole bureaucratic entity not accepting DCO
with the other GNU tools projects accepting it (in particular because we
share code with binutils, so technically we'd have to make a joint decision),
DCO's don't seem to come for free, as we need to track each and every one of
those contributions so we can refer back to them when/if we ever decide to
update/switch licenses or if a legal problem arises.

The contributions are not gdb's, they are still owned by their contributors,
but those are granted the right to be distributed by gdb under the GPL, if I
understand it correctly.

That is potentially a lot of work, and really needs to be taken seriously if
we really want to do things by the book. Makes me wonder how we're supposed
to track this.

Also, I've seen DCO's being sold partially as a mechanism that doesn't require
contributors to share personal information, due to privacy concerns. I don't
think that is true from my reading of it, given we absolutely need to know
how to reach out to the contributor/employer of the contributor in case the
need arises. And that is not even considering things like the contributor
passing away, disappearing etc.

Has this ever been discussed at a higher level across global maintainers of the
other projects?

If all we want is a means to simplify contributions or an alternate way of
contributing for people that don't want to be out in the open personal-
-information-wise, DCO's may not cover it all.

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii via Gdb]

> Date: Tue, 14 Jan 2025 09:49:34 +0000
> Cc: Andrew Pinski <pinskia@gmail.com>, GDB Development <gdb@sourceware.org>,
>  Eli Zaretskii <eliz@gnu.org>, Pedro Alves <pedro@palves.net>,
>  Nick Clifton <nickc@redhat.com>
> From: Luis Machado <luis.machado@arm.com>
> 
> Also, I've seen DCO's being sold partially as a mechanism that doesn't require
> contributors to share personal information, due to privacy concerns. I don't
> think that is true from my reading of it, given we absolutely need to know
> how to reach out to the contributor/employer of the contributor in case the
> need arises. And that is not even considering things like the contributor
> passing away, disappearing etc.

The CA mechanism also has provision for keeping some details
(including even the actual name of the contributor) private, not
exposed in the assignments DB.  You can see some of that in the DB
right now: some people have their names withheld.

So this is not an argument in favor of DCO.

> Has this ever been discussed at a higher level across global maintainers of the
> other projects?

Yes.  There was a big discussion on libs-alpha:

  https://sourceware.org/pipermail/libc-alpha/2021-June/127581.html

and on the Gnulib list:

  https://lists.gnu.org/archive/html/bug-gnulib/2021-06/msg00079.html

and an almost-simultaneous discussion of gnu-prog-discuss:

  https://lists.gnu.org/mailman/private/gnu-prog-discuss/2021q2/016757.html

Some people made really good points there.  For example, check out
these messages from Paul Smith (the GNU Make maintainer):

  https://lists.gnu.org/archive/html/bug-gnulib/2021-06/msg00085.html
  https://lists.gnu.org/archive/html/bug-gnulib/2021-06/msg00095.html

Re: DCO: Was: Re: Contributing to gdb

[Simon Marchi via Gdb]

On 2025-01-14 04:49, Luis Machado via Gdb wrote:
> While I agree having gdb be the sole bureaucratic entity not accepting DCO
> with the other GNU tools projects accepting it (in particular because we
> share code with binutils, so technically we'd have to make a joint decision),
> DCO's don't seem to come for free, as we need to track each and every one of
> those contributions so we can refer back to them when/if we ever decide to
> update/switch licenses or if a legal problem arises.
> 
> The contributions are not gdb's, they are still owned by their contributors,
> but those are granted the right to be distributed by gdb under the GPL, if I
> understand it correctly.
> 
> That is potentially a lot of work, and really needs to be taken seriously if
> we really want to do things by the book. Makes me wonder how we're supposed
> to track this.

My understanding is that the tracking is done using the "Signed-off-by"
git trailer.  I don't know of any project tracking contributions more
extensively than that.

Simon

automated coding style tool (was: RE: DCO: Was: Re: Contributing to gdb)

[Aktemur, Tankut Baris via Gdb]

(forking off the DCO topic)

On Monday, January 13, 2025 6:42 PM Simon Marchi wrote:
> I would be happy if we accepted DCO contributions.  Having to go through
> some copyright assignment paperwork is not the end of the world, but it
> is one of many annoyances that add friction for new contributors (others
> I think of right now are the use of mailing lists for reviews and our
> specific coding style that we are unable to enforce with an automated
> tool).

Regarding the automated coding style tool: is there any active attempt
to pursue this goal?  The latest discussion I know of is this:

  https://inbox.sourceware.org/gdb-patches/9e485731-875c-98e2-1894-6b1a45efa5c5@polymtl.ca/

Tom mentioned his t/clang-format branch in that email thread.  I checked
the branch.  The clang-format config file has

  # BasedOnStyle:  GNU

Is the GDB coding style so off from the built-in GNU style
that it cannot be reused?

-Baris


Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: DCO: Was: Re: Contributing to gdb

[Luis Machado via Gdb]

On 1/14/25 15:10, Simon Marchi wrote:
> 
> 
> On 2025-01-14 04:49, Luis Machado via Gdb wrote:
>> While I agree having gdb be the sole bureaucratic entity not accepting DCO
>> with the other GNU tools projects accepting it (in particular because we
>> share code with binutils, so technically we'd have to make a joint decision),
>> DCO's don't seem to come for free, as we need to track each and every one of
>> those contributions so we can refer back to them when/if we ever decide to
>> update/switch licenses or if a legal problem arises.
>>
>> The contributions are not gdb's, they are still owned by their contributors,
>> but those are granted the right to be distributed by gdb under the GPL, if I
>> understand it correctly.
>>
>> That is potentially a lot of work, and really needs to be taken seriously if
>> we really want to do things by the book. Makes me wonder how we're supposed
>> to track this.
> 
> My understanding is that the tracking is done using the "Signed-off-by"
> git trailer.  I don't know of any project tracking contributions more
> extensively than that.
> 
> Simon

That's what I see as well. But my understanding is that the identifier used
in the Signed-off-by needs to translate to a reachable entity/person. If ever
there is a problem with a particular contribution, whether it needs to be
reverted or the code ownership is being challenged, that person needs to
be reachable so appropriate action could be taken to rectify the situation.

Also, if the project ever wants to do a change/move to new licensing terms,
the project will need the approval of these contributors. Hence my observation
that this seems like a significant amount of work (for the project) that needs to
be done to ensure these contributors are always known and reachable.

From reading things about DCO, it seems to rely on country-specific
interpretations and legal systems. The Signed-off-by git tag may or
may not be enough guarantee compared to CLA's.

Obvious disclaimer, this is from doing some research on the topic. I don't
have a background in legal. But it doesn't seem to me like DCO's are as simple
as just adding tags to git commits as some seem to assume.

Re: DCO: Was: Re: Contributing to gdb

[Mark Wielaard]

Hi,

Adding some FSF and Conservancy people to the CC (see below for Fosdem
related discussion). Bradley, Zoe, Krzysztof, full thread is here:
https://inbox.sourceware.org/gdb/7ac6e62d-1969-41b9-be3f-a2f70344a3eb@simark.ca/T/#u

On Mon, 2025-01-13 at 17:14 +0000, Andrew Burgess via Gdb wrote:
> Luis Machado via Gdb <gdb@sourceware.org> writes:
> > On 6/23/24 23:06, Tom Tromey wrote:
> > > > > I just noticed that GDB (and binutils) are currently not accepting
> > > > > DCO's like both glibc
> > > > > (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
> > > > > and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
> > > > > Has there been any talk about accepting DCOs for gdb and binutils? Or
> > > > > has this not been brought up yet?
> > > 
> > > If gcc, glibc, and binutils accept it, then IMO gdb should as well.
> > 
> > Bumping this thread. I noticed there was a mention of aligning gcc/glibc/binutils in terms
> > of DCO text. That made me wonder where we stand regarding DCO for gdb [1], and if we really
> > want to stray from the other toolchain projects by not making a decision on whether we accept
> > it or not.
> > 
> > [1] https://inbox.sourceware.org/binutils/24b26a75-3b3d-4a00-af92-0b7c331e2db7@redhat.com/
> 
> Based on nothing more than remaining consistent with gcc, binutils, and
> glibc, I think we should make the switch to accepting DCO contributions
> under the same terms that binutils uses[2] (as well as accepting FSF
> assigned contributions).
> 
> I'm volunteering myself to add suitable words to the GDB wiki (based off
> the binutils wording), unless anyone objects.  Ideally I'd like a +1
> from a couple of other global maintainers with no serious objections,
> and I'll go ahead and make the change.
> 
> I think that Eli believes the concerns with FSF assignment are
> overblown, and given the information provided, I'm inclined to agree.
> But at this point, with other components accepting DCO, I'm not sure
> that's really relevant.  Unless there's a super compelling reason why
> GDB should diverge ... I think we should fall into line with the other
> components.
> 
> [2] https://sourceware.org/binutils/wiki/HowToContribute

I kind of agree with Eli. The current contribution policy is pretty
clear. But people seem to be constantly confused about the exact
"rules" of using a DCO and Copyright "ownership".

Specifically what it means for company disclaimers. With the current
process it is clear the FSF will take care of that. With a DCO it
suddenly becomes the responsibility of the individual employees to make
sure the company agrees to them submitting to the project.

That doesn't mean we cannot use a DCO, but it should probably come with
much more explanation and guidance (examples) than what is in the
Binutils wiki.

Are there people going to Fosdem? Krzysztof, the FSF Licensing and
Compliance Manager is holding a panel with GNU maintainers on "Managing
copyrights in free software projects" which seems really relevant to
this discussion:

https://fosdem.org/2025/schedule/event/fosdem-2025-5376-managing-copyrights-in-free-software-projects-discussion-panel-with-gnu-maintainers/

Cheers,

Mark

Re: DCO: Was: Re: Contributing to gdb

[Simon Marchi via Gdb]

On 2025-01-14 10:28, Luis Machado wrote:
> On 1/14/25 15:10, Simon Marchi wrote:
>>
>>
>> On 2025-01-14 04:49, Luis Machado via Gdb wrote:
>>> While I agree having gdb be the sole bureaucratic entity not accepting DCO
>>> with the other GNU tools projects accepting it (in particular because we
>>> share code with binutils, so technically we'd have to make a joint decision),
>>> DCO's don't seem to come for free, as we need to track each and every one of
>>> those contributions so we can refer back to them when/if we ever decide to
>>> update/switch licenses or if a legal problem arises.
>>>
>>> The contributions are not gdb's, they are still owned by their contributors,
>>> but those are granted the right to be distributed by gdb under the GPL, if I
>>> understand it correctly.
>>>
>>> That is potentially a lot of work, and really needs to be taken seriously if
>>> we really want to do things by the book. Makes me wonder how we're supposed
>>> to track this.
>>
>> My understanding is that the tracking is done using the "Signed-off-by"
>> git trailer.  I don't know of any project tracking contributions more
>> extensively than that.
>>
>> Simon
> 
> That's what I see as well. But my understanding is that the identifier used
> in the Signed-off-by needs to translate to a reachable entity/person. If ever
> there is a problem with a particular contribution, whether it needs to be
> reverted or the code ownership is being challenged, that person needs to
> be reachable so appropriate action could be taken to rectify the situation.
>
> Also, if the project ever wants to do a change/move to new licensing terms,
> the project will need the approval of these contributors. Hence my observation
> that this seems like a significant amount of work (for the project) that needs to
> be done to ensure these contributors are always known and reachable.

It is just not possible for all contributors to stay reachable forever.
For instance, people die.  My interpretation is that once we adopt DCO
contributions and there are enough of them in, we accept that the
license will never be changed, as it would be too practically
complicated.  This is the reality for pretty much all projects with a
wide spectrum of contributors, like the Linux kernel.

> 
> From reading things about DCO, it seems to rely on country-specific
> interpretations and legal systems. The Signed-off-by git tag may or
> may not be enough guarantee compared to CLA's.
> 
> Obvious disclaimer, this is from doing some research on the topic. I don't
> have a background in legal. But it doesn't seem to me like DCO's are as simple
> as just adding tags to git commits as some seem to assume.

"not as simple" I suppose.

For some large projects (like the Linux kernel) it seems that easy, so I
keep thinking "if it works for them, with a gazillion more contributions
and big greedy compagnies having stake in it (so the potential for
litigation), why wouldn't it work for us".  But yeah, my opinion is
absolutely not legally informed either, I am really just interested in
simplifying the process, and reducing the unnecessary proces
differences between us and binutils/gcc.  At the end of the day, I
personally don't care who owns the copyright.

I understand the risks that somebody might claim they hold the copyright
when they don't.  I'm not sure how that differs from the contribution
assignment though.  Someone could sign the copyright assignment contract
when they don't really own the copyright in the first place.  If a
company claims ownership of some code contributed by some individual who
signed a copyright assignment but didn't have the right to contribute
it, what would we do today?  Wouldn't we have to go and delete that
code?

Simon

Re: DCO: Was: Re: Contributing to gdb

[Luis Machado via Gdb]

On 1/14/25 15:47, Simon Marchi wrote:
> 
> 
> On 2025-01-14 10:28, Luis Machado wrote:
>> On 1/14/25 15:10, Simon Marchi wrote:
>>>
>>>
>>> On 2025-01-14 04:49, Luis Machado via Gdb wrote:
>>>> While I agree having gdb be the sole bureaucratic entity not accepting DCO
>>>> with the other GNU tools projects accepting it (in particular because we
>>>> share code with binutils, so technically we'd have to make a joint decision),
>>>> DCO's don't seem to come for free, as we need to track each and every one of
>>>> those contributions so we can refer back to them when/if we ever decide to
>>>> update/switch licenses or if a legal problem arises.
>>>>
>>>> The contributions are not gdb's, they are still owned by their contributors,
>>>> but those are granted the right to be distributed by gdb under the GPL, if I
>>>> understand it correctly.
>>>>
>>>> That is potentially a lot of work, and really needs to be taken seriously if
>>>> we really want to do things by the book. Makes me wonder how we're supposed
>>>> to track this.
>>>
>>> My understanding is that the tracking is done using the "Signed-off-by"
>>> git trailer.  I don't know of any project tracking contributions more
>>> extensively than that.
>>>
>>> Simon
>>
>> That's what I see as well. But my understanding is that the identifier used
>> in the Signed-off-by needs to translate to a reachable entity/person. If ever
>> there is a problem with a particular contribution, whether it needs to be
>> reverted or the code ownership is being challenged, that person needs to
>> be reachable so appropriate action could be taken to rectify the situation.
>>
>> Also, if the project ever wants to do a change/move to new licensing terms,
>> the project will need the approval of these contributors. Hence my observation
>> that this seems like a significant amount of work (for the project) that needs to
>> be done to ensure these contributors are always known and reachable.
> 
> It is just not possible for all contributors to stay reachable forever.
> For instance, people die.  My interpretation is that once we adopt DCO
> contributions and there are enough of them in, we accept that the
> license will never be changed, as it would be too practically
> complicated.  This is the reality for pretty much all projects with a
> wide spectrum of contributors, like the Linux kernel.
> 

Right, that's my understanding too.

>>
>> From reading things about DCO, it seems to rely on country-specific
>> interpretations and legal systems. The Signed-off-by git tag may or
>> may not be enough guarantee compared to CLA's.
>>
>> Obvious disclaimer, this is from doing some research on the topic. I don't
>> have a background in legal. But it doesn't seem to me like DCO's are as simple
>> as just adding tags to git commits as some seem to assume.
> 
> "not as simple" I suppose.
> 

True.

> For some large projects (like the Linux kernel) it seems that easy, so I
> keep thinking "if it works for them, with a gazillion more contributions
> and big greedy compagnies having stake in it (so the potential for
> litigation), why wouldn't it work for us".  But yeah, my opinion is
> absolutely not legally informed either, I am really just interested in
> simplifying the process, and reducing the unnecessary proces
> differences between us and binutils/gcc.  At the end of the day, I
> personally don't care who owns the copyright.

The simplification is a big benefit for sure. I guess I just wanted to make
sure I had read enough of it to be able to feel minimally comfortable with
my understanding of how DCO works.

As long as we are fine with the approach, and enough of us have an
understanding of what the DCO path means, I'm fine either way.

> 
> I understand the risks that somebody might claim they hold the copyright
> when they don't.  I'm not sure how that differs from the contribution
> assignment though.  Someone could sign the copyright assignment contract
> when they don't really own the copyright in the first place.  If a
> company claims ownership of some code contributed by some individual who
> signed a copyright assignment but didn't have the right to contribute
> it, what would we do today?  Wouldn't we have to go and delete that
> code?

I suppose both are open to these issues, but with CLA's you get to
review things upfront, which may or may not change much.

> 
> Simon

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii via Gdb]

> Date: Tue, 14 Jan 2025 10:47:03 -0500
> Cc: Andrew Pinski <pinskia@gmail.com>, GDB Development <gdb@sourceware.org>,
>  Eli Zaretskii <eliz@gnu.org>, Pedro Alves <pedro@palves.net>,
>  Nick Clifton <nickc@redhat.com>
> From: Simon Marchi <simark@simark.ca>
> 
> I understand the risks that somebody might claim they hold the copyright
> when they don't.  I'm not sure how that differs from the contribution
> assignment though.  Someone could sign the copyright assignment contract
> when they don't really own the copyright in the first place.  If a
> company claims ownership of some code contributed by some individual who
> signed a copyright assignment but didn't have the right to contribute
> it, what would we do today?  Wouldn't we have to go and delete that
> code?

Yes, we will have to delete it.

As long as we are only considering good-faith mistakes, not deliberate
lies about the authorship and copyright rights, the difference between
CA and DCO is that with the former, one is _required_ to provide a
disclaimer from the employer (if that is relevant; it isn't always),
so this aspect is pretty much in the face of the contributor.  By
contrast, with DCOs one is just asked to declare that he/she has the
rights to contribute the code.  So people might, by omission, make the
mistake of not obtaining the employer's agreement, perhaps because
they are not aware of these aspects, or forget, or...

Re: DCO: Was: Re: Contributing to gdb

[Andrew Burgess via Gdb]

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

> On 1/13/25 17:14, Andrew Burgess wrote:
>> Luis Machado via Gdb <gdb@sourceware.org> writes:
>> 
>>> Hi,
>>>
>>> On 6/23/24 23:06, Tom Tromey wrote:
>>>>>> I just noticed that GDB (and binutils) are currently not accepting
>>>>>> DCO's like both glibc
>>>>>> (https://sourceware.org/glibc/wiki/Contribution%20checklist#Copyright_and_license)
>>>>>> and GCC (https://gcc.gnu.org/contribute.html#legal) are now accepting.
>>>>>> Has there been any talk about accepting DCOs for gdb and binutils? Or
>>>>>> has this not been brought up yet?
>>>>
>>>> If gcc, glibc, and binutils accept it, then IMO gdb should as well.
>>>>
>>>> Tom
>>>
>>> Bumping this thread. I noticed there was a mention of aligning gcc/glibc/binutils in terms
>>> of DCO text. That made me wonder where we stand regarding DCO for gdb [1], and if we really
>>> want to stray from the other toolchain projects by not making a decision on whether we accept
>>> it or not.
>>>
>>> [1] https://inbox.sourceware.org/binutils/24b26a75-3b3d-4a00-af92-0b7c331e2db7@redhat.com/
>> 
>> Based on nothing more than remaining consistent with gcc, binutils, and
>> glibc, I think we should make the switch to accepting DCO contributions
>> under the same terms that binutils uses[2] (as well as accepting FSF
>> assigned contributions).
>> 
>> I'm volunteering myself to add suitable words to the GDB wiki (based off
>> the binutils wording), unless anyone objects.  Ideally I'd like a +1
>> from a couple of other global maintainers with no serious objections,
>> and I'll go ahead and make the change.
>> 
>> I think that Eli believes the concerns with FSF assignment are
>> overblown, and given the information provided, I'm inclined to agree.
>> But at this point, with other components accepting DCO, I'm not sure
>> that's really relevant.  Unless there's a super compelling reason why
>> GDB should diverge ... I think we should fall into line with the other
>> components.
>> 
>> [2] https://sourceware.org/binutils/wiki/HowToContribute
>> 
>> Thanks,
>> Andrew
>> 
>
> I did some reading on DCO's and I have mixed feelings. I haven't followed
> discussions about DCO's on the other GNU tools projects, so it is not clear
> to me yet how/if they addressed the shortcomings of DCO's.
>
> While I agree having gdb be the sole bureaucratic entity not accepting DCO
> with the other GNU tools projects accepting it (in particular because we
> share code with binutils, so technically we'd have to make a joint decision),
> DCO's don't seem to come for free, as we need to track each and every one of
> those contributions so we can refer back to them when/if we ever decide to
> update/switch licenses or if a legal problem arises.

I wonder how an attempt to switch licence for GDB would work given we
statically link against libbfd, which can already include DCO code?

Thanks,
Andrew

Re: automated coding style tool

[Tom Tromey]

>>>>> Aktemur, Tankut Baris via Gdb <gdb@sourceware.org> writes:

> Regarding the automated coding style tool: is there any active attempt
> to pursue this goal?

Every year or two I take another look at clang-format.
The discussion is here:

https://sourceware.org/bugzilla/show_bug.cgi?id=30098

> Tom mentioned his t/clang-format branch in that email thread.  I checked
> the branch.  The clang-format config file has
>   # BasedOnStyle:  GNU
> Is the GDB coding style so off from the built-in GNU style
> that it cannot be reused?

I don't recall why I commented this out.  Anyway clang-format doesn't
come very close to GNU style.  I'd be ok with ignoring most of the
little differences (i.e., I don't care about goto label placement), but
the bin packing output is just super ugly some of the time.

Tom

Re: automated coding style tool

[Luis Machado via Gdb]

On 1/14/25 17:11, Tom Tromey wrote:
>>>>>> Aktemur, Tankut Baris via Gdb <gdb@sourceware.org> writes:
> 
>> Regarding the automated coding style tool: is there any active attempt
>> to pursue this goal?
> 
> Every year or two I take another look at clang-format.
> The discussion is here:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=30098
> 
>> Tom mentioned his t/clang-format branch in that email thread.  I checked
>> the branch.  The clang-format config file has
>>   # BasedOnStyle:  GNU
>> Is the GDB coding style so off from the built-in GNU style
>> that it cannot be reused?
> 
> I don't recall why I commented this out.  Anyway clang-format doesn't
> come very close to GNU style.  I'd be ok with ignoring most of the
> little differences (i.e., I don't care about goto label placement), but
> the bin packing output is just super ugly some of the time.
> 
> Tom

I'd go for a tool, even if it is slightly to moderately different from what
we tend to use. It's not like the GNU style has been updated to cope with
the more recent C++ syntax, so we have some stuff that isn't properly
documented.

The tool would simplify that.

Also, the style of comment we use (/* */) doesn't go well with clang-format
from what I recall. But we can just drop options that deal with comments.

Re: automated coding style tool

[Simon Marchi via Gdb]

On 2025-01-14 12:11, Tom Tromey wrote:
> I don't recall why I commented this out.  Anyway clang-format doesn't
> come very close to GNU style.  I'd be ok with ignoring most of the
> little differences (i.e., I don't care about goto label placement), but
> the bin packing output is just super ugly some of the time.
> 
> Tom

I don't know how often those ugly outputs happen, but it is possible to
disable clang-format locally, like this:

https://github.com/efficios/babeltrace/blob/5105ea10985ef0512878ff3f9bc8e1092735e75c/src/cpp-common/bt2/field-path.hpp#L106-L114

So if it's a relatively rare occurence that the output is atrociously
bad enough to make your eyes bleed, the benefit of the tool is still
there.

Simon

Re: automated coding style tool

[Simon Marchi via Gdb]

On 2025-01-14 12:14, Luis Machado wrote:
> I'd go for a tool, even if it is slightly to moderately different from what
> we tend to use. It's not like the GNU style has been updated to cope with
> the more recent C++ syntax, so we have some stuff that isn't properly
> documented.

I agree.

The style has to be precisely defined if everybody needs to do
formatting by hand, and we want the result to be consistent.  But with
the tool, you say "the style is whatever the tool outputs", and that
clears sooo much mental space.  I don't see the absolute need for the
auto-formatted code to follow to the letter whatever style we apply by
hand today.

If we don't like what the tool outputs, we can argue over than and
change the tool.

Also, if are missing some features to get the output we want, nobody is
going to magically implement them for us.  And if we don't use the tool,
there's no motivation for us either to go implement the changes.  I
think that the only way to get the ball rolling is to start using the
tool, even if the output is not ideal, and then if there's something
really annoying, one of us *might* have the motivation to go improve the
tool.

Simon

Re: automated coding style tool

[Tom Tromey]

Simon> If we don't like what the tool outputs, we can argue over than
Simon> and change the tool.

Yeah - but that's where we're already at.  Like, I ran clang-format on
gdb and read the diffs and found a bunch of things I didn't like.  IIRC
the main offenders were bin-packing.  I imagine Pedro did this too,
since he's made similar comments in the past.

I at least CCd myself on upstream bugs against the tool.  I commented
on some, maybe filed some too (don't remember).

I'm not super interested in hacking on clang-format, but the tool is
there and all the information for someone who is.

Simon> Also, if are missing some features to get the output we want, nobody is
Simon> going to magically implement them for us.  And if we don't use the tool,
Simon> there's no motivation for us either to go implement the changes.  I
Simon> think that the only way to get the ball rolling is to start using the
Simon> tool, even if the output is not ideal, and then if there's something
Simon> really annoying, one of us *might* have the motivation to go improve the
Simon> tool.

I'm in favor of using a tool but my view is that it has to meet some
minimal standard of usefulness.  I just think clang-format does not do
this.

Tom

Re: automated coding style tool

[Maciej W. Rozycki]

On Tue, 14 Jan 2025, Tom Tromey wrote:

> Simon> Also, if are missing some features to get the output we want, nobody is
> Simon> going to magically implement them for us.  And if we don't use the tool,
> Simon> there's no motivation for us either to go implement the changes.  I
> Simon> think that the only way to get the ball rolling is to start using the
> Simon> tool, even if the output is not ideal, and then if there's something
> Simon> really annoying, one of us *might* have the motivation to go improve the
> Simon> tool.
> 
> I'm in favor of using a tool but my view is that it has to meet some
> minimal standard of usefulness.  I just think clang-format does not do
> this.

 We have a coding style tool onboard our GNU Project already, it's called 
GNU indent and I think it would be consistent with our project to improve 
the tool we already have rather than seeking alternatives outside.

 FWIW,

  Maciej

Re: DCO: Was: Re: Contributing to gdb

[Maciej W. Rozycki]

On Tue, 14 Jan 2025, Luis Machado via Gdb wrote:

> While I agree having gdb be the sole bureaucratic entity not accepting DCO
> with the other GNU tools projects accepting it (in particular because we
> share code with binutils, so technically we'd have to make a joint decision),
> DCO's don't seem to come for free, as we need to track each and every one of
> those contributions so we can refer back to them when/if we ever decide to
> update/switch licenses or if a legal problem arises.

 It happened with QEMU once, 10+ years ago, and a considerable amount of 
code had to be pulled out just because the original contributors couldn't 
be chased.  I don't have a reference handy, but surely the event can be 
tracked.

> Also, I've seen DCO's being sold partially as a mechanism that doesn't require
> contributors to share personal information, due to privacy concerns. I don't
> think that is true from my reading of it, given we absolutely need to know
> how to reach out to the contributor/employer of the contributor in case the
> need arises. And that is not even considering things like the contributor
> passing away, disappearing etc.

 It did happen with said QEMU relicensing and a former colleague of mine 
who had passed away.  While I was absolutely certain he wouldn't mind he 
wasn't available anymore to speak out.

  Maciej

Re: automated coding style tool

[Luis Machado via Gdb]

On 1/14/25 23:04, Tom Tromey wrote:
> Simon> If we don't like what the tool outputs, we can argue over than
> Simon> and change the tool.
> 
> Yeah - but that's where we're already at.  Like, I ran clang-format on
> gdb and read the diffs and found a bunch of things I didn't like.  IIRC
> the main offenders were bin-packing.  I imagine Pedro did this too,
> since he's made similar comments in the past.
> 
> I at least CCd myself on upstream bugs against the tool.  I commented
> on some, maybe filed some too (don't remember).
> 
> I'm not super interested in hacking on clang-format, but the tool is
> there and all the information for someone who is.
> 
> Simon> Also, if are missing some features to get the output we want, nobody is
> Simon> going to magically implement them for us.  And if we don't use the tool,
> Simon> there's no motivation for us either to go implement the changes.  I
> Simon> think that the only way to get the ball rolling is to start using the
> Simon> tool, even if the output is not ideal, and then if there's something
> Simon> really annoying, one of us *might* have the motivation to go improve the
> Simon> tool.
> 
> I'm in favor of using a tool but my view is that it has to meet some
> minimal standard of usefulness.  I just think clang-format does not do
> this.

That's fair. But are we factoring in the amount of time spent over the years
telling contributors "you forgot a space here", "two spaces after period"?

I tend to think that is not a good use of one's time. I reviewed some output
from applying clang-format --style=gnu on gdb's sources, and it looks generally
fine to me.

Some stuff is a bit different and some other stuff is very different. But
personally I'm willing to see this automation go through and I'm fine
adapting to a potentially new format, whatever that is.

I might've mentioned this already, but for folks that deal with multiple projects,
the norm is to have to deal with varying styles. So it becomes even more of a burden
to try to remember the GNU style that mostly applies to C and not C++, even though
the project is C++ now.

In summary what I want to say is that I'd go for it. If later we want to tweak
things, we can. This sounds like it agrees with Simon as well.

Re: DCO: Was: Re: Contributing to gdb

[Mark Wielaard]

Hi Luis,

On Tue, Jan 14, 2025 at 09:49:34AM +0000, Luis Machado via Gdb wrote:
> Also, I've seen DCO's being sold partially as a mechanism that
> doesn't require contributors to share personal information, due to
> privacy concerns. I don't think that is true from my reading of it,
> given we absolutely need to know how to reach out to the
> contributor/employer of the contributor in case the need arises. And
> that is not even considering things like the contributor passing
> away, disappearing etc.

There is indeed some confusion about anonymous and/or pseudonomous
contributions. Where the main issue really is that there is a
difference between someones "real" (legal) name and how they identify
themselves. Various projects have handled that in different ways. The
current proposed clarification [1] for the GCC project reads:

    The name you use as your identity should not be an anonymous id or
    false name that misrepresents who you are.

    A known identity can be the committer's real, birth or legal name,
    but can also be an established (online) identity.  It is the name
    you convey to people in the community for them to use to identify
    you as you.  The key concern is that your identification is
    sufficient enough to contact you if an issue were to arise in the
    future about your contribution.  You should not deliberately use a
    name or email address that hides your identity.  When you wish to
    only contribute under an (anonymous) pseudonym, or when you
    require an explicit employer disclaimer, then following the FSF
    assignment process is more appropriate.

Cheers,

Mark

[1] https://inbox.sourceware.org/gcc-patches/8faf15ae-1009-8da9-12c8-c0cd6a0ec9e4@pfeifer.com/

Re: DCO: Was: Re: Contributing to gdb

[Mark Wielaard]

Hi Andrew,

On Tue, Jan 14, 2025 at 04:46:14PM +0000, Andrew Burgess via Gdb wrote:
> Luis Machado <luis.machado@arm.com> writes:
> > DCO's don't seem to come for free, as we need to track each and
> > every one of those contributions so we can refer back to them
> > when/if we ever decide to update/switch licenses or if a legal
> > problem arises.
> 
> I wonder how an attempt to switch licence for GDB would work given we
> statically link against libbfd, which can already include DCO code?

In general you have to think of how to handle that up-front. Using an
"or (at your option) any later version" license already helps.

In the case of the DCO that binutils uses it has the clause "I have
the right ... under the same open source license (unless I am
permitted to submit under a different license), as indicated in the
file".

That would then just needs a clarification that you aren't permitted
to submit under a different license. In general we want contributors
to grant all rights the GPL grants, including the "or any later
version" rights.

For elfutils, and some other projects, we solved that by making the
DCO explicit about granting all rights under all licenses that might
cover the project files (and different files have different, dual,
license terms). So our version of the DCO [1] reads:

    I have the right to submit the contribution under each license
    indicated in, or otherwise designated as being applicable to, the
    file.

Cheers,

Mark

[1] https://sourceware.org/cgit/elfutils/tree/CONTRIBUTING#n25

Re: DCO: Was: Re: Contributing to gdb

[Mark Wielaard]

Hi Eli,

On Tue, Jan 14, 2025 at 06:42:59PM +0200, Eli Zaretskii via Gdb wrote:
> As long as we are only considering good-faith mistakes, not deliberate
> lies about the authorship and copyright rights, the difference between
> CA and DCO is that with the former, one is _required_ to provide a
> disclaimer from the employer (if that is relevant; it isn't always),
> so this aspect is pretty much in the face of the contributor.  By
> contrast, with DCOs one is just asked to declare that he/she has the
> rights to contribute the code.  So people might, by omission, make the
> mistake of not obtaining the employer's agreement, perhaps because
> they are not aware of these aspects, or forget, or...

One thing we could do to make it easier for people contributing work
for their employer is follow what the Samba does for their DCO [1].

Someone wishing to contribute work under the DCO simply first sends a
copy of the whole DCO from their corporate email address declaring
they have permission to contribute to Samba from their employer under
the indicated licenses to a special "contributing" email address. The
Samba project then keeps a copy of that email as a record that the
submitter has the rights to contribute code.

We could ask the FSF copyright-clerk to do that for us. After the
copyright-clerk receives that declaration people are then fine to
submit Signed-off-by patches from their employers email address.

It doesn't prevent all mistakes, but at least makes clear that if you
contribute on behave of your company you have to check you have the
rights. And the explicit email has the added benefit that we can show
we had a company disclaimer on file.

Cheers,

Mark

[1] https://www.samba.org/samba/devel/copyright-policy.html

RE: automated coding style tool

[Aktemur, Tankut Baris via Gdb]

On Wednesday, January 15, 2025 11:20 AM Luis Machado wrote:
> On 1/14/25 23:04, Tom Tromey wrote:
> > Simon> If we don't like what the tool outputs, we can argue over than
> > Simon> and change the tool.
> >
> > Yeah - but that's where we're already at.  Like, I ran clang-format on
> > gdb and read the diffs and found a bunch of things I didn't like.  IIRC
> > the main offenders were bin-packing.  I imagine Pedro did this too,
> > since he's made similar comments in the past.
> >
> > I at least CCd myself on upstream bugs against the tool.  I commented
> > on some, maybe filed some too (don't remember).
> >
> > I'm not super interested in hacking on clang-format, but the tool is
> > there and all the information for someone who is.
> >
> > Simon> Also, if are missing some features to get the output we want, nobody is
> > Simon> going to magically implement them for us.  And if we don't use the tool,
> > Simon> there's no motivation for us either to go implement the changes.  I
> > Simon> think that the only way to get the ball rolling is to start using the
> > Simon> tool, even if the output is not ideal, and then if there's something
> > Simon> really annoying, one of us *might* have the motivation to go improve the
> > Simon> tool.
> >
> > I'm in favor of using a tool but my view is that it has to meet some
> > minimal standard of usefulness.  I just think clang-format does not do
> > this.
> 
> That's fair. But are we factoring in the amount of time spent over the years
> telling contributors "you forgot a space here", "two spaces after period"?
> 
> I tend to think that is not a good use of one's time. I reviewed some output
> from applying clang-format --style=gnu on gdb's sources, and it looks generally
> fine to me.
> 
> Some stuff is a bit different and some other stuff is very different. But
> personally I'm willing to see this automation go through and I'm fine
> adapting to a potentially new format, whatever that is.
> 
> I might've mentioned this already, but for folks that deal with multiple projects,
> the norm is to have to deal with varying styles. So it becomes even more of a burden
> to try to remember the GNU style that mostly applies to C and not C++, even though
> the project is C++ now.
> 
> In summary what I want to say is that I'd go for it. If later we want to tweak
> things, we can. This sounds like it agrees with Simon as well.

FWIW, I'd also be in favor of having a clang-format configuration available
in the GDB repo.  Such tools will always have false-positives and may require
some human involvement occasionally.  I think the potential benefits are appealing.

Regards,
-Baris


Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: DCO: Was: Re: Contributing to gdb

[Florian Weimer via Gdb]

* Eli Zaretskii via Gdb:

>> From: Andrew Burgess <aburgess@redhat.com>
>> Cc: Andrew Pinski <pinskia@gmail.com>, GDB Development <gdb@sourceware.org>,
>>  Eli Zaretskii <eliz@gnu.org>
>> Date: Mon, 13 Jan 2025 17:14:41 +0000
>> 
>> I think that Eli believes the concerns with FSF assignment are
>> overblown, and given the information provided, I'm inclined to agree.
>> But at this point, with other components accepting DCO, I'm not sure
>> that's really relevant.  Unless there's a super compelling reason why
>> GDB should diverge ... I think we should fall into line with the other
>> components.
>
> I mostly fear that by accepting DCOs we will open ourselves to
> contributions from people who are not authorized to contribute their
> code (e.g., it was copied from somewhere, or their employment contract
> makes all their code the property of their employer, or something of
> that nature).  DCO makes it much easier to submit code based on
> incorrect understanding of what the DCO text says, so the probability
> for honest mistakes is higher than with CA.

It is possible that someone signs a copyright assignment without being
authorized to do so, which is exactly the same problem.  As far as I
know, the FSF doesn't verify that the signer has been authorized by the
organization that owns the rights.  In general, this can be quite
difficult to do.  Whether that's more or less likely to happen than a
DCO mis-submission is hard to tell.

Thanks,
Florian

Re: DCO: Was: Re: Contributing to gdb

[Florian Weimer via Gdb]

* Mark Wielaard:

> I kind of agree with Eli. The current contribution policy is pretty
> clear. But people seem to be constantly confused about the exact
> "rules" of using a DCO and Copyright "ownership".
>
> Specifically what it means for company disclaimers. With the current
> process it is clear the FSF will take care of that. With a DCO it
> suddenly becomes the responsibility of the individual employees to make
> sure the company agrees to them submitting to the project.

But having a copyright assignment with the FSF does not change that at
all: an individual authorized by an organization to submit contributions
in principle still needs to determine if any particular change can be
contributed according to company rules.

Thanks,
Florian

Re: DCO: Was: Re: Contributing to gdb

[Luis Machado via Gdb]

On 1/17/25 10:37, Florian Weimer wrote:
> * Eli Zaretskii via Gdb:
> 
>>> From: Andrew Burgess <aburgess@redhat.com>
>>> Cc: Andrew Pinski <pinskia@gmail.com>, GDB Development <gdb@sourceware.org>,
>>>  Eli Zaretskii <eliz@gnu.org>
>>> Date: Mon, 13 Jan 2025 17:14:41 +0000
>>>
>>> I think that Eli believes the concerns with FSF assignment are
>>> overblown, and given the information provided, I'm inclined to agree.
>>> But at this point, with other components accepting DCO, I'm not sure
>>> that's really relevant.  Unless there's a super compelling reason why
>>> GDB should diverge ... I think we should fall into line with the other
>>> components.
>>
>> I mostly fear that by accepting DCOs we will open ourselves to
>> contributions from people who are not authorized to contribute their
>> code (e.g., it was copied from somewhere, or their employment contract
>> makes all their code the property of their employer, or something of
>> that nature).  DCO makes it much easier to submit code based on
>> incorrect understanding of what the DCO text says, so the probability
>> for honest mistakes is higher than with CA.
> 
> It is possible that someone signs a copyright assignment without being
> authorized to do so, which is exactly the same problem.  As far as I
> know, the FSF doesn't verify that the signer has been authorized by the
> organization that owns the rights.  In general, this can be quite
> difficult to do.  Whether that's more or less likely to happen than a
> DCO mis-submission is hard to tell.
> 
> Thanks,
> Florian
> 

I suppose someone going through the trouble of actually signing a contract
is a bit more effort than just sticking a Signed-Off-By tag in a commit.

Doesn't feel like those two things are at the same level, but others may
disagree.

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii via Gdb]

> From: Florian Weimer <fweimer@redhat.com>
> Cc: Andrew Burgess <aburgess@redhat.com>,  Eli Zaretskii <eliz@gnu.org>,
>   luis.machado@arm.com,  tom@tromey.com,  blarsen@redhat.com,
>   pinskia@gmail.com
> Date: Fri, 17 Jan 2025 11:37:54 +0100
> 
> * Eli Zaretskii via Gdb:
> 
> > I mostly fear that by accepting DCOs we will open ourselves to
> > contributions from people who are not authorized to contribute their
> > code (e.g., it was copied from somewhere, or their employment contract
> > makes all their code the property of their employer, or something of
> > that nature).  DCO makes it much easier to submit code based on
> > incorrect understanding of what the DCO text says, so the probability
> > for honest mistakes is higher than with CA.
> 
> It is possible that someone signs a copyright assignment without being
> authorized to do so, which is exactly the same problem.  As far as I
> know, the FSF doesn't verify that the signer has been authorized by the
> organization that owns the rights.

verification is not the issue here, the issue is whether the
contributor is at all aware of this aspect.

The copyright assignment process includes the contributor filling a
form, where he/she is asked whether they have an employer that should
be included in the process:

  [Do you have an employer who might have a basis to claim to own
  your changes?  Do you attend a school which might make such a claim?]

I think reasonable people will always know to answer those questions,
or at least ask the FSF copyright clerk what is the meaning of "an
employer who might have a basis to claim to own your changes" (and
similarly the meaning of the question about the school).

By contrast, AFAIK there's no such process in sending the DCO.

Re: DCO: Was: Re: Contributing to gdb

[Eli Zaretskii via Gdb]

> From: Florian Weimer <fweimer@redhat.com>
> Cc: Andrew Burgess <aburgess@redhat.com>,  Luis Machado
>  <luis.machado@arm.com>,  Tom Tromey <tom@tromey.com>,  Guinevere Larsen
>  <blarsen@redhat.com>,  Andrew Pinski <pinskia@gmail.com>,  GDB Development
>  <gdb@sourceware.org>,  Eli Zaretskii <eliz@gnu.org>,  "Bradley M. Kuhn"
>  <bkuhn@sfconservancy.org>,  zoe@fsf.org,  ksiewicz@fsf.org
> Date: Fri, 17 Jan 2025 11:42:19 +0100
> 
> * Mark Wielaard:
> 
> > I kind of agree with Eli. The current contribution policy is pretty
> > clear. But people seem to be constantly confused about the exact
> > "rules" of using a DCO and Copyright "ownership".
> >
> > Specifically what it means for company disclaimers. With the current
> > process it is clear the FSF will take care of that. With a DCO it
> > suddenly becomes the responsibility of the individual employees to make
> > sure the company agrees to them submitting to the project.
> 
> But having a copyright assignment with the FSF does not change that at
> all: an individual authorized by an organization to submit contributions
> in principle still needs to determine if any particular change can be
> contributed according to company rules.

I think you are talking about the (relatively rare, AFAIU) situation
with employees of companies, such as Google, which have blanket
disclaimer for its employees to contribute code.  But most
contributors are not in that category: they are not "authorized" up
front to submit contributions.  They need to ask the employer to sign
an explicit disclaimer for their contributions, usually for a
relatively short period (like 5 or 10 years), after which, if the
person still works for the same company, the disclaimer needs to be
renewed.

As for determining whether any change can be contributed according to
company rules, see my other message: the assignment form explicitly
asks that question, so the contributor should find out the answer and
mention that in the form he/she submits.  If they don't know what
their employment contract says, they will have to find out when
filling the form.

Re: automated coding style tool

[Andrew Burgess via Gdb]

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

> On 1/14/25 23:04, Tom Tromey wrote:
>> Simon> If we don't like what the tool outputs, we can argue over than
>> Simon> and change the tool.
>> 
>> Yeah - but that's where we're already at.  Like, I ran clang-format on
>> gdb and read the diffs and found a bunch of things I didn't like.  IIRC
>> the main offenders were bin-packing.  I imagine Pedro did this too,
>> since he's made similar comments in the past.
>> 
>> I at least CCd myself on upstream bugs against the tool.  I commented
>> on some, maybe filed some too (don't remember).
>> 
>> I'm not super interested in hacking on clang-format, but the tool is
>> there and all the information for someone who is.
>> 
>> Simon> Also, if are missing some features to get the output we want, nobody is
>> Simon> going to magically implement them for us.  And if we don't use the tool,
>> Simon> there's no motivation for us either to go implement the changes.  I
>> Simon> think that the only way to get the ball rolling is to start using the
>> Simon> tool, even if the output is not ideal, and then if there's something
>> Simon> really annoying, one of us *might* have the motivation to go improve the
>> Simon> tool.
>> 
>> I'm in favor of using a tool but my view is that it has to meet some
>> minimal standard of usefulness.  I just think clang-format does not do
>> this.
>
> That's fair. But are we factoring in the amount of time spent over the years
> telling contributors "you forgot a space here", "two spaces after period"?

I don't think adding this tool is going to be the magic bullet everyone
seems to think it is.

As a reviewer you'll either still need to learn the style in order to
spot when a contributor has not running the formatting tool.  Either
that, or you need to apply each patch locally and the check run the
formatting tool to check the formatting is correct.

And the "two spaces after a period" rule is for comments, so that's not
going to change (I hope).  I mean, it's not that I care about 2 spaces
vs 1, but we need _a_ rule so that we have consistency.

I think if GDB could just move away from the mailing list and each users
pushes their own patches model, over to a pull request style approach,
then we could potentially have _real_ automated checks, e.g. checking
the formatting.  Then we have an _actual_ win.

> I tend to think that is not a good use of one's time. I reviewed some output
> from applying clang-format --style=gnu on gdb's sources, and it looks generally
> fine to me.
>
> Some stuff is a bit different and some other stuff is very different. But
> personally I'm willing to see this automation go through and I'm fine
> adapting to a potentially new format, whatever that is.

Like you, I don't particularly care what the preferred style is, just so
long as we pick something and stick to it.  I just don't think using a
particular tool is going to be the win everyone seems to think it is.

Just my thoughts.

Thanks,
Andrew

Re: automated coding style tool

[Joel Brobecker via Gdb]

> I don't think adding this tool is going to be the magic bullet everyone
> seems to think it is.
> 
> As a reviewer you'll either still need to learn the style in order to
> spot when a contributor has not running the formatting tool.  Either
> that, or you need to apply each patch locally and the check run the
> formatting tool to check the formatting is correct.

I have experience with a project where developers were asked to install
a pre-commit check that would run the formatting tool, but where we did
not have (yet) a pipeline to verify the formatting at submission time.
This project had a lot of developers, some of them very occasional.

It's true that, at first, we had a number developers forgot to install
that pre-commit hook, and ended up submitting ill formatted code.

What I noticed, at least for myself, is that with time you start
developing an eye for what the expected formatting is like. And when
I noticed something odd, I'd just ask if they installed the pre-commit
and ran the formatting tool. If they say no, I pointed them to
the directions, and asked them to retest and resubmit. Ultimately,
we mostly converged.

And for the cases we didn't notice at review - no big issue.
The formatting shouldn't be horrible of the reviewer would have
noticed it, so no great harm -- certainly no worse than right now.
And later on, the next developer touching the same file ends up
noticing that the formatting seems wrong. It's a bit of a pain
for them to first run the formatting tool and push a pure-reformatting
commit.  But we tell the contributor who forgot, they install the tool,
and normally we eventually converge.

Another things we can imagine doing is a nightly job on sourceware
that runs the nightly snapshot through the formatting tool, and
sends an email with a list of files that are not conformant.

Where I think it might be painful is which version of the tool
to use. Different versions will likely have slightly different
results in terms of formatting the code. You might want to require
a specific version and check for that version, to avoid different
users having different ways of formatting the same code.

> I think if GDB could just move away from the mailing list and each users
> pushes their own patches model, over to a pull request style approach,
> then we could potentially have _real_ automated checks, e.g. checking
> the formatting.  Then we have an _actual_ win.

Seconded.

In a model like this, you don't have to ask. You run a job that
checks it, and you know if it's conformant or not.

-- 
Joel

Re: automated coding style tool

[Simon Marchi via Gdb]

On 1/17/25 10:13 AM, Joel Brobecker wrote:
>> I don't think adding this tool is going to be the magic bullet everyone
>> seems to think it is.
>>
>> As a reviewer you'll either still need to learn the style in order to
>> spot when a contributor has not running the formatting tool.  Either
>> that, or you need to apply each patch locally and the check run the
>> formatting tool to check the formatting is correct.
> 
> I have experience with a project where developers were asked to install
> a pre-commit check that would run the formatting tool, but where we did
> not have (yet) a pipeline to verify the formatting at submission time.
> This project had a lot of developers, some of them very occasional.
> 
> It's true that, at first, we had a number developers forgot to install
> that pre-commit hook, and ended up submitting ill formatted code.
> 
> What I noticed, at least for myself, is that with time you start
> developing an eye for what the expected formatting is like. And when
> I noticed something odd, I'd just ask if they installed the pre-commit
> and ran the formatting tool. If they say no, I pointed them to
> the directions, and asked them to retest and resubmit. Ultimately,
> we mostly converged.
> 
> And for the cases we didn't notice at review - no big issue.
> The formatting shouldn't be horrible of the reviewer would have
> noticed it, so no great harm -- certainly no worse than right now.
> And later on, the next developer touching the same file ends up
> noticing that the formatting seems wrong. It's a bit of a pain
> for them to first run the formatting tool and push a pure-reformatting
> commit.  But we tell the contributor who forgot, they install the tool,
> and normally we eventually converge.
> 
> Another things we can imagine doing is a nightly job on sourceware
> that runs the nightly snapshot through the formatting tool, and
> sends an email with a list of files that are not conformant.
> 
> Where I think it might be painful is which version of the tool
> to use. Different versions will likely have slightly different
> results in terms of formatting the code. You might want to require
> a specific version and check for that version, to avoid different
> users having different ways of formatting the same code.

I agree with all the above.

We will definitely want to choose a specific version of the tool.  If we
end up using clang-format, that version will likely not be available out
of the box for all distros, but there are other ways to get it.  I don't
know how it works on Windows though, since I don't develop on Windows
much.  We can cross that bridge when we get there.

>> I think if GDB could just move away from the mailing list and each users
>> pushes their own patches model, over to a pull request style approach,
>> then we could potentially have _real_ automated checks, e.g. checking
>> the formatting.  Then we have an _actual_ win.
> 
> Seconded.
> 
> In a model like this, you don't have to ask. You run a job that
> checks it, and you know if it's conformant or not.

I don't agree with Andrew, in that even without a proper pre-merge CI,
you do save time by using a tool to format the code, over doing and
reviewing it manually.

Of course, like Joel said, ill-formatted code will certainly get
committed at some point, but the nightly job will tell us.  It's a quick
fix - one person pushes an obvious patch - and we carry on.  Much less
time overall than pointing out formatting issues one by one (for the
reviewer) and fixing them by hand (for the author).  This is what we do
with our Python code and it works well, I think.

I suppose it would also be possible to write a server-side commit hook
that checks whether the formatting of the affected files is correct, and
reject the push if not.

Simon

Re: automated coding style tool

[Phi via Gdb]

On 17/01/2025 16:55, Simon Marchi via Gdb wrote:

> 
> Of course, like Joel said, ill-formatted code will certainly get
> committed at some point, but the nightly job will tell us.  It's a quick

Just curious about this interesting thread. I'd like to understand the ill-formatted concept while using a code formatter. I was wondering a !ill-formatted, i.e a well-formatted should always produce a no diff output on its input, I mean 

$ format-tool foo.c

must produce foo.c with no diff's, a hook of some kind can be implemented may be at commit or push time (or git-send-mail) saying the format-tool must be run first and QA re-run. 

I jumped into this trail, so may this has been discussed already.

Cheers.

Re: automated coding style tool

[Simon Marchi via Gdb]

On 1/17/25 12:36 PM, Phi via Gdb wrote:
> 
> 
> On 17/01/2025 16:55, Simon Marchi via Gdb wrote:
> 
>>
>> Of course, like Joel said, ill-formatted code will certainly get
>> committed at some point, but the nightly job will tell us.  It's a quick
> 
> Just curious about this interesting thread. I'd like to understand the ill-formatted concept while using a code formatter. I was wondering a !ill-formatted, i.e a well-formatted should always produce a no diff output on its input, I mean 
> 
> $ format-tool foo.c
> 
> must produce foo.c with no diff's

I once had a situation where clang-format would ping pong between two
formattings for a given line of code when running multiple times on the
same file.  This was an unfortunate bug, but easily circumvented by
adding a /* clang-format off */ annotation.  Given the amount of code
that this tool has formatted without any problem for me, I can forgive
this one bug :).

> a hook of some kind can be implemented may be at commit or push time (or git-send-mail) saying the format-tool must be run first and QA re-run. 

We were discussing the merits of using a tool to format the code if
there is not pre-push check, if the responsibility to run the tool
solely falls on each contributor doing it on their side.  Some
ill-formatted code will get pushed at some point.  My point is that it's
not the end of the world, and it's still better than using no tool at
all.  But of course, something that blocks the push if ill-formatted
code is present is even better.

Simon

Re: automated coding style tool

[Tom Tromey]

>>>>> "Maciej" == Maciej W Rozycki <macro@orcam.me.uk> writes:

Maciej>  We have a coding style tool onboard our GNU Project already, it's called 
Maciej> GNU indent and I think it would be consistent with our project to improve 
Maciej> the tool we already have rather than seeking alternatives outside.

That would be good but I think GNU indent is mostly unmaintained.
The last time I looked at it, it didn't know very much about C++ at all.

Tom

Re: automated coding style tool

[Tom Tromey]

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

>> I'm in favor of using a tool but my view is that it has to meet some
>> minimal standard of usefulness.  I just think clang-format does not do
>> this.

Luis> That's fair. But are we factoring in the amount of time spent over the years
Luis> telling contributors "you forgot a space here", "two spaces after period"?

Yes, of course I did.

I review a lot of patches.  My feeling is that formatting is
occasionally an issue, particularly with newcomers, but not really a big
part of review.  Bad formatting can be a signal that a patch requires
more attention, because experienced developers try to make their changes
conform to the style of the surrounding code -- so discrepancies mean
you may be dealing with someone who isn't so adept.

On the other hand, I also read a lot of code.  And, my view overall is
that readability is far more important than ease of formatting.  And,
furthermore, I dislike some aspects of clang-format's output, on
readability grounds.

Luis> Some stuff is a bit different and some other stuff is very different. But
Luis> personally I'm willing to see this automation go through and I'm fine
Luis> adapting to a potentially new format, whatever that is.

Me too, but within some bounds.

Luis> I might've mentioned this already, but for folks that deal with
Luis> multiple projects,

FWIW I also deal with multiple projects.

Tom

Re: DCO: Was: Re: Contributing to gdb

[Mark Wielaard]

Hi Florian,

On Fri, Jan 17, 2025 at 11:42:19AM +0100, Florian Weimer wrote:
> * Mark Wielaard:
> 
> > I kind of agree with Eli. The current contribution policy is pretty
> > clear. But people seem to be constantly confused about the exact
> > "rules" of using a DCO and Copyright "ownership".
> >
> > Specifically what it means for company disclaimers. With the current
> > process it is clear the FSF will take care of that. With a DCO it
> > suddenly becomes the responsibility of the individual employees to make
> > sure the company agrees to them submitting to the project.
> 
> But having a copyright assignment with the FSF does not change that at
> all: an individual authorized by an organization to submit contributions
> in principle still needs to determine if any particular change can be
> contributed according to company rules.

Yes, in theory the situation is the same. But in the first case there
is an explicit question, while in the second it is implicit. While I
think it is fine for the community to rely on either the explicit or
implicit company disclaimer provided it seems more honest to be
explicit about it. Once the contribution is made the community will
rely on the certification made and the company cannot back out
anymore. It feels bad "tricking" companies into submissions. So imho
it would be good to make that explicitly clear in the explanation,
examples or text of the DCO and/or to have an explicit company
disclaimer on file like the Samba project does [*].

Cheers,

Mark

[*] https://www.samba.org/samba/devel/copyright-policy.html

Re: automated coding style tool

[Luis Machado via Gdb]

On 1/18/25 18:56, Tom Tromey wrote:
>>>>>> "Luis" == Luis Machado <luis.machado@arm.com> writes:
> 
>>> I'm in favor of using a tool but my view is that it has to meet some
>>> minimal standard of usefulness.  I just think clang-format does not do
>>> this.
> 
> Luis> That's fair. But are we factoring in the amount of time spent over the years
> Luis> telling contributors "you forgot a space here", "two spaces after period"?
> 
> Yes, of course I did.

Sorry, it was more a rhetorical question. I wasn't implying you had not.

> 
> I review a lot of patches.  My feeling is that formatting is
> occasionally an issue, particularly with newcomers, but not really a big
> part of review.  Bad formatting can be a signal that a patch requires
> more attention, because experienced developers try to make their changes
> conform to the style of the surrounding code -- so discrepancies mean
> you may be dealing with someone who isn't so adept.
> 
> On the other hand, I also read a lot of code.  And, my view overall is
> that readability is far more important than ease of formatting.  And,
> furthermore, I dislike some aspects of clang-format's output, on
> readability grounds.

I think readability is important as well. My personal take on it is that formatting
might make less of a difference compared to how the code is actually written.

In particular excessive templating, lambda's, macros and excessive use of auto are things
that tend to bring readability down for me. But they tidy up the code somewhat, so it is
a compromise I guess.

> 
> Luis> Some stuff is a bit different and some other stuff is very different. But
> Luis> personally I'm willing to see this automation go through and I'm fine
> Luis> adapting to a potentially new format, whatever that is.
> 
> Me too, but within some bounds.
> 
> Luis> I might've mentioned this already, but for folks that deal with
> Luis> multiple projects,
> 
> FWIW I also deal with multiple projects.

I'm aware of that. I think it came out a bit off, but I wasn't implying
you didn't. Sorry if that sounded like that.

> 
> Tom

Re: DCO: Was: Re: Contributing to gdb

[Guinevere Larsen via Gdb]

On 1/17/25 10:01 AM, Eli Zaretskii wrote:
>> From: Florian Weimer <fweimer@redhat.com>
>> Cc: Andrew Burgess <aburgess@redhat.com>,  Eli Zaretskii <eliz@gnu.org>,
>>    luis.machado@arm.com,  tom@tromey.com,  blarsen@redhat.com,
>>    pinskia@gmail.com
>> Date: Fri, 17 Jan 2025 11:37:54 +0100
>>
>> * Eli Zaretskii via Gdb:
>>
>>> I mostly fear that by accepting DCOs we will open ourselves to
>>> contributions from people who are not authorized to contribute their
>>> code (e.g., it was copied from somewhere, or their employment contract
>>> makes all their code the property of their employer, or something of
>>> that nature).  DCO makes it much easier to submit code based on
>>> incorrect understanding of what the DCO text says, so the probability
>>> for honest mistakes is higher than with CA.
>> It is possible that someone signs a copyright assignment without being
>> authorized to do so, which is exactly the same problem.  As far as I
>> know, the FSF doesn't verify that the signer has been authorized by the
>> organization that owns the rights.
> verification is not the issue here, the issue is whether the
> contributor is at all aware of this aspect.
>
> The copyright assignment process includes the contributor filling a
> form, where he/she is asked whether they have an employer that should
> be included in the process:
>
>    [Do you have an employer who might have a basis to claim to own
>    your changes?  Do you attend a school which might make such a claim?]
>
> I think reasonable people will always know to answer those questions,
> or at least ask the FSF copyright clerk what is the meaning of "an
> employer who might have a basis to claim to own your changes" (and
> similarly the meaning of the question about the school).
>
> By contrast, AFAIK there's no such process in sending the DCO.
>
We could have a similar process.

A way to ensure that a contributor has seen the DCO could be setting up 
a bot, and whenever an email with an SOB with a never before seen email, 
the bot sends a boilerplate "Welcome to the project. Before we can 
accept, please be sure to review the following, and reply in line that 
you meet the conditions."

And after the reply, we can be reasonably sure the contributor knows 
what a DCO entails.

When I mentioned this to Andrew, he had a simpler idea, just to setup 
some "gdb-dco" list, where contributors who want to contribute with DCO 
would send the DCO wording with an "OK" or the name or pseudonym they'll 
be using to contribute. There's less automation and a little more 
annoyances to end contributors, but it is easier than signing a contract 
- especially for contributors whose mother tongue isn't english - and 
has a result immediately, as opposed to waiting for over a month at times.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

Re: automated coding style tool

[Maciej W. Rozycki]

On Sat, 18 Jan 2025, Tom Tromey wrote:

> Maciej>  We have a coding style tool onboard our GNU Project already, it's called 
> Maciej> GNU indent and I think it would be consistent with our project to improve 
> Maciej> the tool we already have rather than seeking alternatives outside.
> 
> That would be good but I think GNU indent is mostly unmaintained.
> The last time I looked at it, it didn't know very much about C++ at all.

 The most recent release was made in 2023 and the previous one -- back in 
2018.  Not too bad per GNU Project's standards, so I wouldn't consider the 
program unmaintained, but rather that not much development has happened in 
the recent years because, unsurprisingly, support for C has been pretty 
much complete.

 I realise it has no C++ support, but as software engineers and then also 
contributors to the GNU Project we are in the best position to change it. 
So I think that if there's a tool out there that either already fulfils 
our needs or almost does and could be brought to completion very easily, 
then it will make sense to invest our resources in it, but otherwise we 
should really consider improving GNU indent instead.

 FWIW,

  Maciej

Re: DCO

[Bradley M. Kuhn via Gdb]

Hey GDB folks,

I'm not on this list, but I'm a big fan of GDB and have been doing work
adjacent to and in support of GDB and all the toolchain communities for some
time.  I read with interest this DCO thread you've been having; I'm grateful
that you cc'ed me, as I do have some experience and knowledge about the
situation that I think might be helpful.  In the past, I have also been
involved in these discussions from inside the FSF — but I haven't been
affiliated with the FSF since 2019.  As such, I can give perspective from
having had different vantage points at different times.

First of all, the DCO is a rather neat trick of legal hackery, and it works
ok for Linux but the reason it works well in the Linux project is somewhat
unique to Linux.  The most important thing I want to draw the GDB community's
attention to is that the DCO is specifically designed to shift the blame and
burden for improperly licensed code ending up in the codebase *onto the
individual developers personally*.  This works great for companies, as it
limits their liability.  In practice, it's rare anyone gets sued, so Linux
folks are ok with the legal hack.  But I regularly urge developers to think
carefully if they really want to take on such risk themselves.

My position is nuanced: copyright assignment to a trusted non-profit is a
really good tool for defending users' rights, but it has to be weighed
against the convenience and ease of contribution, and that calculation is
very hard to do.  One of the huge benefits of the FSF's copyright
assignment/disclaimer process is that it forces every developer to have a
really important conversation with their employer that they often don't
bother to have:

   (a) is it ok that I'm contributing this upstream?, and

   (b) what is the proper copyright holder arrangement for such
       contributions? , and

   (c) do we (employer/employee) all really agree about (b)?

Those are painful conversations, but it's a good thing if they happen as
early as possible.  Also, those conversations should occur *even if* a
developer isn't assigning copyright to a third party.  By default, absent a
separate agreement, an employee's copyrights will be assigned to their
employer anyway via "Work for Hire" (as it's called in the USA, and there are
similar doctrines around the world).

Those are a few reasons why my usual recommendation is that a project adapt
the Linux DCO text for the needs of a their specific project (i.e., one size
does not always fit all).  For example, the Samba Project decided to require
in their Certificate that contributors explicitly license under a v3-group
license.  Samba did this for for various reasons — including that it protects
the project and the developers better than the Linux DCO:
  https://gitlab.com/samba-team/devel/samba/-/blob/master/README.contributing

Most importantly, my concern is that individual developers who don't want to
assign to a charity (e.g., FSF or SFC) *push back* on their employers and
instead demand employment contracts that let employees personally keep their
own copyrights in the Free Software projects they contribute to.

Ultimately, individuals make up Free Software projects, and I support the
idea that a project have individual voices as part of its copyright holdings
(i.e., I am sympathetic to those who don't want a projects' copyright
assigned 100% to any organization, even if it's a charity.)  But, I don't
think an oligarchy of copyright holders — whereby the copyright is held
mostly by for-profit employers — serves Free Software's community-oriented,
charitable, and individual-developer-and-user-minded goals.  We have observed
that application of the DCO method of contribution (without a more
comprehensive plan) often leads to that oligarchical outcome over time.

I'm glad to discuss these topics more on this thread, offer my time to help
GDB on how to implement a DCO-like solution effectively, and I also hope to
reprise the licensing BoF at Cauldron this year to discuss these issues more.
(We spent much of the time in the 2024 Licensing BoF discussing this very
issue.)

Also, IANAL, TINLA, and I also, as mentioned, I have not been affilaited with
the FSF since 2019.  Nevertheless, I suspect that FSF folks would agree with
most (but not all) of my views above, and I see they're cc'ed and hope
they'lll also comment sharing their views.

Sincerely,
--
Bradley M. Kuhn - he/them
Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
========================================================================
Become a Conservancy Sustainer today: https://sfconservancy.org/sustainer

Re: DCO

[Krzysztof Siewicz via Gdb]

Hello,

Thank you Mark for CCing the FSF on that thread. I'm the FSF's licensing 
and compliance manager and let me please also add Craig Topham, FSF's 
copyright and licensing associate so that our complete Licensing Team 
can participate in the discussion. We are not on this list and it took 
us some time to catch up with your conversation.
We at the FSF have once promised to accept DCOs and to draft variant(s) 
of theDCO that would best serve the needs of the GNU project. So we are 
happy that this discussion takes place and that so many people 
communicate their needs and have informed opinions about ways for having 
the needs met. Since the last Cauldron, we have been meaning to look at 
the DCO again, and we're happy to work with people at GDB to help 
implement something directly.

I hope it is OK for you if I present the FSF's position and rationale 
towards copyright assignments, and what guides us when considering DCOs.

DCOs sound like a great tool for cutting bureaucratic overhead in a 
project, but it comes at a cost that should be well understood and risks 
that should be managed. For the time being, copyright assignments bring 
a lot of certainty and security, but with an overhead, so perhaps we 
should focus on minimizing the overhead instead of dropping assignments 
altogether. I explain in detail below why:
The FSF's copyright handling policy is designedwithenforcement of the 
GNU GPLvia copyright actionsin mind. Other goals are: to give FSF 
explicit permission to include the material in a GNU package, to make it 
possible to add additional permission to specific pieces of code, and to 
protect the community from employers' surprise claims (including patent 
claims).
The FSF asks contributors for two kinds of legal papers: copyright 
assignments, and employer copyright disclaimers. Sometimes, for small 
parts of programs we also accept placing them in the public domain or 
giving the FSF an unlimited perpetual nonexclusive license.
Employer disclaimers are important, including for effective GPL 
enforcement. If we accepted a copyright assignment but it turned out 
that copyrights had been actually held by the employer, the copyright 
assignment would not transfer any rights to the FSF. The employer 
disclaimer used by the FSF also addressesthe employer's patents and 
interface copyrights that might cover the contributor's code.

 From what we know, projects collecting DCOs do not require separate 
employer disclaimers, but this looks less burdensome for developers only 
at first glance. AsBradley noted in his post, the Linux DCO text simply 
shifts all the burden for these important tasks onto the individual 
developer. The developer must personallymake sure that the employer 
won't claim copyrights or patents on the code. Also, DCOs are issued by 
employees, not employers. So even if a DCO includes a statement of the 
employee that no employer can claim rights on the code, it is hardly 
equivalent to such a statement made directly by the employer. Whatever 
the contributor agreed with the employer might be not enforceable by the 
project or users, and they are definitely more legally secure if the 
employer issues a disclaimer towards the project and its users directly.
Copyright assignment by its nature includes a transfer of standing to 
bring copyright claims undera license and to add additional permissions. 
We believe that GPL enforcement via copyright is very important for the 
future of software freedom. Thus, the FSF is and will remain committed 
to holding copyrights to preserve software freedom. This is not 
guaranteed for projects where copyrights are assigned toorganizations 
with no commitment to uphold the GPL for the community, e.g. to 
for-profit employers of the developers, that could as well be 
incentivized to relicense the code under a nonfree license.
I hope this is helpful. This is not legal advice as the FSF cannot give 
legal advice, but it is intended to clarify our policy approach. We are 
open to hearing any ideas for improving our copyright handling policy. 
FSF is also hosting a panel at FOSDEM in the Legal and Policy DevRoom 
about some of these issues in a few weeks and I welcome those interested 
to find us there H.1301 (Cornil) on Saturday at 12:30: 
https://fosdem.org/2025/schedule/event/fosdem-2025-5376-managing-copyrights-in-free-software-projects-discussion-panel-with-gnu-maintainers/
If you have any questions, do not hesitate to contact us.

Best regards,


-- 
Krzysztof Siewicz | Licensing and Compliance Manager, Free Software Foundation
GPG Key: 6DC9 E663 36DB 9588 81AB 7E43 2671 24EF FC9C D84E
https://fsf.org

We moved! The FSF changed address, find us at:https://www.fsf.org/about/contact

Free software is important for a free society!
Build a better world with us by matching the average donation of USD $46.22
https://donate.fsf.org

Give the gift of an FSF associate membership:
https://my.fsf.org/gift-a-membership

Follow the FSF on Mastodon:https://hostux.social/@fsf

Sign up for the FSF's newsletter:https://www.fsf.org/fss

US government employee? Use CFC charity code 63210 to support us through
the Combined Federal Campaign.https://cfcgiving.opm.gov/

Re: DCO

[Guinevere Larsen via Gdb]

On 1/27/25 12:55 PM, Bradley M. Kuhn wrote:
> Hey GDB folks,
>
> I'm not on this list, but I'm a big fan of GDB and have been doing work
> adjacent to and in support of GDB and all the toolchain communities for some
> time.  I read with interest this DCO thread you've been having; I'm grateful
> that you cc'ed me, as I do have some experience and knowledge about the
> situation that I think might be helpful.  In the past, I have also been
> involved in these discussions from inside the FSF — but I haven't been
> affiliated with the FSF since 2019.  As such, I can give perspective from
> having had different vantage points at different times.
>
> First of all, the DCO is a rather neat trick of legal hackery, and it works
> ok for Linux but the reason it works well in the Linux project is somewhat
> unique to Linux.  The most important thing I want to draw the GDB community's
> attention to is that the DCO is specifically designed to shift the blame and
> burden for improperly licensed code ending up in the codebase *onto the
> individual developers personally*.  This works great for companies, as it
> limits their liability.  In practice, it's rare anyone gets sued, so Linux
> folks are ok with the legal hack.  But I regularly urge developers to think
> carefully if they really want to take on such risk themselves.
>
> My position is nuanced: copyright assignment to a trusted non-profit is a
> really good tool for defending users' rights, but it has to be weighed
> against the convenience and ease of contribution, and that calculation is
> very hard to do.

There is another factor that you did not include in your calculation, 
which is the user actually finding the FSF a trusted non-profit. 
Regardless of any personal opinions I can have on the matter, I know 
that several programmers don't think that, and some of them are 
potential contributors to the GDB project (a personal acquaintance of 
mine has said so explicitly, and more than one implicitly).

By only having the copyright assignment we are implicitly reducing the 
pool of contributors to those that trust the FSF.

> One of the huge benefits of the FSF's copyright
> assignment/disclaimer process is that it forces every developer to have a
> really important conversation with their employer that they often don't
> bother to have:
>
>     (a) is it ok that I'm contributing this upstream?, and
>
>     (b) what is the proper copyright holder arrangement for such
>         contributions? , and
>
>     (c) do we (employer/employee) all really agree about (b)?
>
> Those are painful conversations, but it's a good thing if they happen as
> early as possible.  Also, those conversations should occur *even if* a
> developer isn't assigning copyright to a third party.  By default, absent a
> separate agreement, an employee's copyrights will be assigned to their
> employer anyway via "Work for Hire" (as it's called in the USA, and there are
> similar doctrines around the world).
>
> Those are a few reasons why my usual recommendation is that a project adapt
> the Linux DCO text for the needs of a their specific project (i.e., one size
> does not always fit all).  For example, the Samba Project decided to require
> in their Certificate that contributors explicitly license under a v3-group
> license.  Samba did this for for various reasons — including that it protects
> the project and the developers better than the Linux DCO:
>    https://gitlab.com/samba-team/devel/samba/-/blob/master/README.contributing
>
> Most importantly, my concern is that individual developers who don't want to
> assign to a charity (e.g., FSF or SFC) *push back* on their employers and
> instead demand employment contracts that let employees personally keep their
> own copyrights in the Free Software projects they contribute to.
>
> Ultimately, individuals make up Free Software projects, and I support the
> idea that a project have individual voices as part of its copyright holdings
> (i.e., I am sympathetic to those who don't want a projects' copyright
> assigned 100% to any organization, even if it's a charity.)  But, I don't
> think an oligarchy of copyright holders — whereby the copyright is held
> mostly by for-profit employers — serves Free Software's community-oriented,
> charitable, and individual-developer-and-user-minded goals.  We have observed
> that application of the DCO method of contribution (without a more
> comprehensive plan) often leads to that oligarchical outcome over time.

Another option for relaxing the need for CA could be that, if a user is 
doing contributions in their free time and unrelated to any work, they 
could use DCO, while someone contributing in a professional capacity 
would need to sign the CA. This would be enforced through emails: If it 
is something that looks professional (ie something that looks like 
email<at>company<dot>TLD) we'd know this goes through their employment, 
while something that looks end-user (ie, something like 
whatever<at>gmail/yahoo/university<dot>com), DCO would suffice, and for 
emails that we can't be sure, we could just ask the user.

This would lower the bar immensely for students or unemployed people, 
while not allowing for-profit companies to have most of the copyright of 
the project. We should still incentivize people who are employed but 
contributing in their free time to talk to their employer, but I think 
it isn't standard practice for employers to have copyright over things 
you do in your free time (at least not in Brazil), so I would think that 
DCO would still be acceptable in that case.

>
> I'm glad to discuss these topics more on this thread, offer my time to help
> GDB on how to implement a DCO-like solution effectively, and I also hope to
> reprise the licensing BoF at Cauldron this year to discuss these issues more.
> (We spent much of the time in the 2024 Licensing BoF discussing this very
> issue.)
>
> Also, IANAL, TINLA, and I also, as mentioned, I have not been affilaited with
> the FSF since 2019.  Nevertheless, I suspect that FSF folks would agree with
> most (but not all) of my views above, and I see they're cc'ed and hope
> they'lll also comment sharing their views.
>
> Sincerely,
> --
> Bradley M. Kuhn - he/them
> Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy
> ========================================================================
> Become a Conservancy Sustainer today: https://sfconservancy.org/sustainer
>

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

Re: DCO

[Mark Wielaard]

Hi Gwen,

On Mon, Jan 27, 2025 at 02:22:57PM -0300, Guinevere Larsen wrote:
> On 1/27/25 12:55 PM, Bradley M. Kuhn wrote:
> >My position is nuanced: copyright assignment to a trusted non-profit is a
> >really good tool for defending users' rights, but it has to be weighed
> >against the convenience and ease of contribution, and that calculation is
> >very hard to do.
> 
> There is another factor that you did not include in your
> calculation, which is the user actually finding the FSF a trusted
> non-profit. Regardless of any personal opinions I can have on the
> matter, I know that several programmers don't think that, and some
> of them are potential contributors to the GDB project (a personal
> acquaintance of mine has said so explicitly, and more than one
> implicitly).
> 
> By only having the copyright assignment we are implicitly reducing
> the pool of contributors to those that trust the FSF.

Thanks for bringing up the elephant in the room.  I think you are
right and I agree that the FSF has not shown itself very
trustworthy. Personally I struggle a lot with this. The FSF should be
there for all GNU developers, contributors and maintainers. But in
practice they are protecting someone who harasses anybody who even
dares to say they feel abused or theatened by him or the people around
him.

https://gnu.wildebeest.org/blog/mjw/2021/03/24/fsf-associate-membership/

While that issue hasn't been dealt with I don't think we can require
anybody assigning their copyright to the FSF. So we do need some other
way to increase the pool of contributors. Maybe that is some kind of
DCO, or finding another organization that people can trust to assign
copyright to.

I do hope that the FSF being willing to at least discuss this issue
now is a first step to reconciliation.

> Another option for relaxing the need for CA could be that, if a user
> is doing contributions in their free time and unrelated to any work,
> they could use DCO, while someone contributing in a professional
> capacity would need to sign the CA. This would be enforced through
> emails: If it is something that looks professional (ie something
> that looks like email<at>company<dot>TLD) we'd know this goes
> through their employment, while something that looks end-user (ie,
> something like whatever<at>gmail/yahoo/university<dot>com), DCO
> would suffice, and for emails that we can't be sure, we could just
> ask the user.
> 
> This would lower the bar immensely for students or unemployed
> people, while not allowing for-profit companies to have most of the
> copyright of the project. We should still incentivize people who are
> employed but contributing in their free time to talk to their
> employer, but I think it isn't standard practice for employers to
> have copyright over things you do in your free time (at least not in
> Brazil), so I would think that DCO would still be acceptable in that
> case.

Sadly it is standard practice for employers (and even universities) to
claim rights over their employers or students even when done outside
"work hours". This isn't actually legal in various jurisdictions. And
then you might win if the company sues you. So it would be much better
if you just talked to your employer about what you are going to do,
even if it is outside "work". That way there is no confusion and your
Signed-off-by really means that it is your own work and there are no
other people making claims on you work.

I do think we should trust people making such a statement. But we
should also make the text of the DCO (explanation/example) really
clear that we expect someone to have had that difficult conversation.

Cheers,

Mark