Re: Where to send issues

[Carlos O'Donell <carlos@redhat.com>]

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.