Re: Where to send issues

[Konstantin Kharlamov <Hi-Angel@yandex.ru>]

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