Re: Preferred way to submit a very large batch of bugs?

From: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, shihao zhong <zhong950419(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Malis <malis(at)pgrust(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Subject: Re: Preferred way to submit a very large batch of bugs?
Date: 2026-11-05 08:47:14
Message-ID: CABPTF7U=ikStWmuC8w6GR-4FVPHo5s28c8_ZGPmMA8=Sx1+mgw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 5, 2026 at 4:03 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
>
> On Thu, 05 Nov 2026, Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> > I am wondering whether it's helpful to build a
> > temporary site or use existing tools to track those bugs after
> > filtering, auditing and grouping them.
>
> That's the direction we are going with hackorum.dev. It already makes
> reading/searching/using the lists much easier, and we are working on
> many features that will move it even more towards a proper bug tracker
> / review tool based on the mailing list. You can also suggest ideas or
> PRs :) (we are already working on LLM-assisted automatic grouping, for
> example, soon available)

Thanks for informing me about this. It looks useful. I'll take a closer look.

> > Another complementary tool that
> > seems helpful is something like the sashiko review system from the
> > linux community
>
> Thanks, that's a useful link I didn't know about. I already built
> something similar during the year (for now privately) for reviewing
> patches, which is based on the claude/codex CLI, so it works with
> subscriptions instead of API based billing. The long term goal with
> that is also to automatically run it for every patch submission (and
> commits, as sometimes there are changes between the last patch and the
> committed code), and to make it public, but I want to make it really
> good before I publish it.

There're lots of discussions and controversies on the use of this tool
in the linux community. Nevertheless, It seems to be a
growingly-useful tool thanks to the advancement of both the model and
harness.. I was thinking of building something similar for a while,
but was not able to do it because of the limited bandwidth. You can
share it to the mailing list when it is mature. But I also think
there're advantages of sharing a basically-working POC project, it
would receive helpful potential feedback and contributions at the
early stage.

> > That said, not sure about the degree of
> > that demand since there's a likely ceiling to the current growth of
> > bug reports
>
> I would be still more worried about the part that without a human
> actually looking at it, we are just risking disclosing/finding
> security issues more easier. I know LLMs are already capable of
> finding many, but we shouldn't make it even more easier by just
> dumping lots of unreviewed bugreports on the internet.

Yeah, it needs to separate security issues from others.

--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-11-05 08:47:20 Re: [PATCH] dynahash.c refactoring
Previous Message JoongHyuk Shin 2026-11-05 08:42:50 Re: [PATCH] Add recovery boundary WAL record for database and tablespace commands