Re: BUG #18784: Bugs and BugTracking - Mailing list pgsql-bugs

Hello

On 2025-Jan-24, PG Bug reporting form wrote:

> While going through the pgsql-bugs i found out there is no proper website or
> a system to monitor bugs or to track bug status ,i have also referred
> this bug
> https://www.postgresql.org/message-id/flat/5618263A.40806%40agliodbs.com#a8cc0869f5a3273df07c59fb8e2dde05
>  but i can't find that  website is working now.

This refers to the following
https://granicus.if.org/pgbugs/
which was an experiment with a bug tracker from 2015 that gave no fruit.

> I have created and dummy repo and tried to push some bugs ,Kindly find the
> attachment of demo data below.

I didn't see any attachment to this email, but I doubt that a system
that doesn't feed directly from the mailing list traffic is going to go
anywhere with this community.  A manually maintained github repo seems
unworkable.

I described what I see as working during last year's pgconf.dev
developer's meeting, namely a system very similar to our patch
tracker^W^W commitfest app, which would contain links to pgsql-bugs
threads.  The app, in addition to listing the relevant thread links for
each bug, would allow simple metadata such as affected Postgres
branches, SHA1 git commit IDs (indicating point at which each bug was
fixed on each branch), maybe a simple tagging system.  No discussion
would take place on the app itself, since that should continue to be
relegated to mailing lists.

It would be possible to create bugs in that system in two ways: one,
using the already existing bug reporting form, which would assign the
bug number, post to pgsql-bugs and create the bug metadata in the new
system; two, by manually accepting a link to a thread in some mailing
list (probably pgsql-hackers, but it could be any other
@lists.postgresql.org list), whereby a new bug number would be assigned
but no additional mail is sent.

I think this wouldn't require much new code, because, as I said, it
would be very similar to the commitfest app, so it's quite likely that
we could reuse a lot of that.  It would be a separate app, however,
because though they are similar, the requirements are different enough.


Why do I think this would be successful?  Many years ago, there was a
proposal that would use Debian's bugtracker, which is essentially a
glorified mailing list with per-bug archives, plus a lot of smarts to
know when to close a bug.  This had the most traction among this
community, but the idea died down when it was clear that 1) the Debian
community was not really open to sharing their stuff, and 2) nobody
offered to maintain this.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/