Where to send issues

Where to send issues

[Lukáš Jiřiště]

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

Hello everyone,
this is exciting as this is my first time ever using mailing list.
I'm writing this, because I wanted to know, where to submit a minor typo in
the GNU libc manual or whether there's a way I can fix it myself.
Thank you all in advance. Have a nice day.

Lukáš Jiřiště

Re: Where to send issues

[Konstantin Kharlamov]

On Wed, 2024-01-24 at 09:05 +0100, Lukáš Jiřiště via Libc-help wrote:
> Hello everyone,
> this is exciting as this is my first time ever using mailing list.
> I'm writing this, because I wanted to know, where to submit a minor
> typo in
> the GNU libc manual or whether there's a way I can fix it myself.
> Thank you all in advance. Have a nice day.

You can fix it yourself and send to a libc-alpha@sourceware.org ML. But
Glibc is very tough to contribute to because of lack of reviews for
patches, so patches often just hang in there for years. I've seen it
both from the side (you often see people ping over and over) and I have
myself a series of small fixes from 2019 or something that I was
pinging but to my knowledge by this day nobody reviewed it.

So unless you are motivated to ping over and over, I'd advice just fill
a bugreport. You can do that here
https://sourceware.org/bugzilla/enter_bug.cgi, chose "libc" as a
product.

Re: Where to send issues

[Konstantin Kharlamov]

On Wed, 2024-01-24 at 11:15 +0300, Konstantin Kharlamov wrote:
> On Wed, 2024-01-24 at 09:05 +0100, Lukáš Jiřiště via Libc-help wrote:
> > Hello everyone,
> > this is exciting as this is my first time ever using mailing list.
> > I'm writing this, because I wanted to know, where to submit a minor
> > typo in
> > the GNU libc manual or whether there's a way I can fix it myself.
> > Thank you all in advance. Have a nice day.
> 
> You can fix it yourself and send to a libc-alpha@sourceware.org ML.
> But
> Glibc is very tough to contribute to because of lack of reviews for
> patches, so patches often just hang in there for years. I've seen it
> both from the side (you often see people ping over and over) and I
> have
> myself a series of small fixes from 2019 or something that I was
> pinging but to my knowledge by this day nobody reviewed it.

Ah, and you also need to sign some documents to be able to contribute
to glibc 😂 FTR, I have signed it, it's just an oddness that GNU
projects have. So, yeah, there's that as well 😄

> So unless you are motivated to ping over and over, I'd advice just
> fill
> a bugreport. You can do that here
> https://sourceware.org/bugzilla/enter_bug.cgi, chose "libc" as a
> product.

Re: Where to send issues

[Szabolcs Nagy]

The 01/24/2024 09:05, Lukáš Jiřiště via Libc-help wrote:
> Hello everyone,
> this is exciting as this is my first time ever using mailing list.
> I'm writing this, because I wanted to know, where to submit a minor typo in
> the GNU libc manual or whether there's a way I can fix it myself.
> Thank you all in advance. Have a nice day.
> 
> Lukáš Jiřiště

https://sourceware.org/glibc/involved.html

Re: Where to send issues

[Carlos O'Donell]

On 1/24/24 03:19, Konstantin Kharlamov wrote:
> On Wed, 2024-01-24 at 11:15 +0300, Konstantin Kharlamov wrote:
>> On Wed, 2024-01-24 at 09:05 +0100, Lukáš Jiřiště via Libc-help wrote:
>>> Hello everyone,
>>> this is exciting as this is my first time ever using mailing list.
>>> I'm writing this, because I wanted to know, where to submit a minor
>>> typo in
>>> the GNU libc manual or whether there's a way I can fix it myself.
>>> Thank you all in advance. Have a nice day.
>>
>> You can fix it yourself and send to a libc-alpha@sourceware.org ML.
>> But
>> Glibc is very tough to contribute to because of lack of reviews for
>> patches, so patches often just hang in there for years. I've seen it
>> both from the side (you often see people ping over and over) and I
>> have
>> myself a series of small fixes from 2019 or something that I was
>> pinging but to my knowledge by this day nobody reviewed it.
> 
> Ah, and you also need to sign some documents to be able to contribute
> to glibc 😂 FTR, I have signed it, it's just an oddness that GNU
> projects have. So, yeah, there's that as well 😄

Today the project accepts contributions without copyright assignment.

https://sourceware.org/glibc/wiki/Contribution%20checklist

You can just use DCO e.g. "Signed-off-by:" if you can attest to the Developer
Certificate of Origin as Linux kernel developers do.

>> So unless you are motivated to ping over and over, I'd advice just
>> fill
>> a bugreport. You can do that here
>> https://sourceware.org/bugzilla/enter_bug.cgi, chose "libc" as a
>> product.

I'm sorry to hear that you had a bad experience trying to contribute :-(

It is indeed a problem that FOSS projects lack sufficient maintainer resources
to review incoming patches.

We try to help out with that by having a weekly Monday morning patch queue review.

https://sourceware.org/glibc/wiki/PatchworkReviewMeetings

The intent of the meetings is to allow the community to attend and raise patches
they would like reviewed.

We track 2 metrics for the patch queue:
- How many currently need to be reviewed e.g. State NEW delegate NOBODY.
- How many days on average the patches have been in the queue.

The latter metric is at ~260 days, which is a number I watch to see what we
can do e.g. spend a week reviewing patches or not.

We are trying to use pre-commit CI to make it easier to commit simpler patches.
https://patchwork.sourceware.org/project/glibc/list/

I see patches from you in 2019 which predate our start of the patch queue review
and the pre-commit CI work. Please feel free to repost them if they still apply
and we'll see if we can get them committed.

-- 
Cheers,
Carlos.

Re: Where to send issues

[Konstantin Kharlamov]

Awww, thank you very much! I'm glad to hear the situation is improved
so much! I'll see if the patches still apply, thank you again!

On Wed, 2024-01-24 at 08:44 -0500, Carlos O'Donell wrote:
> On 1/24/24 03:19, Konstantin Kharlamov wrote:
> > On Wed, 2024-01-24 at 11:15 +0300, Konstantin Kharlamov wrote:
> > > On Wed, 2024-01-24 at 09:05 +0100, Lukáš Jiřiště via Libc-help
> > > wrote:
> > > > Hello everyone,
> > > > this is exciting as this is my first time ever using mailing
> > > > list.
> > > > I'm writing this, because I wanted to know, where to submit a
> > > > minor
> > > > typo in
> > > > the GNU libc manual or whether there's a way I can fix it
> > > > myself.
> > > > Thank you all in advance. Have a nice day.
> > > 
> > > You can fix it yourself and send to a
> > > libc-alpha@sourceware.org ML.
> > > But
> > > Glibc is very tough to contribute to because of lack of reviews
> > > for
> > > patches, so patches often just hang in there for years. I've seen
> > > it
> > > both from the side (you often see people ping over and over) and
> > > I
> > > have
> > > myself a series of small fixes from 2019 or something that I was
> > > pinging but to my knowledge by this day nobody reviewed it.
> > 
> > Ah, and you also need to sign some documents to be able to
> > contribute
> > to glibc 😂 FTR, I have signed it, it's just an oddness that GNU
> > projects have. So, yeah, there's that as well 😄
> 
> Today the project accepts contributions without copyright assignment.
> 
> https://sourceware.org/glibc/wiki/Contribution%20checklist
> 
> You can just use DCO e.g. "Signed-off-by:" if you can attest to the
> Developer
> Certificate of Origin as Linux kernel developers do.
> 
> > > So unless you are motivated to ping over and over, I'd advice
> > > just
> > > fill
> > > a bugreport. You can do that here
> > > https://sourceware.org/bugzilla/enter_bug.cgi, chose "libc" as a
> > > product.
> 
> I'm sorry to hear that you had a bad experience trying to contribute
> :-(
> 
> It is indeed a problem that FOSS projects lack sufficient maintainer
> resources
> to review incoming patches.
> 
> We try to help out with that by having a weekly Monday morning patch
> queue review.
> 
> https://sourceware.org/glibc/wiki/PatchworkReviewMeetings
> 
> The intent of the meetings is to allow the community to attend and
> raise patches
> they would like reviewed.
> 
> We track 2 metrics for the patch queue:
> - How many currently need to be reviewed e.g. State NEW delegate
> NOBODY.
> - How many days on average the patches have been in the queue.
> 
> The latter metric is at ~260 days, which is a number I watch to see
> what we
> can do e.g. spend a week reviewing patches or not.
> 
> We are trying to use pre-commit CI to make it easier to commit
> simpler patches.
> https://patchwork.sourceware.org/project/glibc/list/
> 
> I see patches from you in 2019 which predate our start of the patch
> queue review
> and the pre-commit CI work. Please feel free to repost them if they
> still apply
> and we'll see if we can get them committed.
>