Does anyone have a link to a collective list of all known bugs in PostgreSQL?
This seems to be the canonical list.
The claim that PostgreSQL does not have a bug tracker is not entirely accurate - there is no bugzilla/debbugs/...-style bugtracker (although it's a recurrent topic in discussions), but we do have pgsql-bugs mailing list. Which is mostly fine, as long as you fix bugs promptly and don't keep unsolved bugs lying around for years.
If you need to know what was fixed in a particular release, see either the release notes (high-level summary), or commits in the stable branches (those are typically just bugfixes, and the commit messages usually include a link to the relevant pgsql-bugs thread).
* careful patch review process - Sometimes it's a bit grueling, and it takes time to get stuff in, but it's extremely valuable. Not only for finding bugs but alternative approaches to implementing the feature.
* careful testing - It's a natural part of the review process (Does the patch have tests? Can I come up with something weird that makes it fail?). Of course, there's a bunch of machines with very different configurations (OS, hw resources, ...) that are generally quite good in finding race conditions, incorrect assumptions in the code, ...
* bugfixing - Someone reported a bug on pgsql-bugs? Challenge accepted. Customer reported a bug internally? Better fix it ASAP.
A mailing list hardly seems like an efficient method for tracking bugs unless a major part of the efficiency is reducing signal to noise by make it more difficult for non-developer or non-paying users to file bugs
I can't speak for other devs contributing to the project, but I think the mailing list is a great way to do this. Ultimately, what you want is a simple way to track information about reported issues, discuss the details, make it reasonably simple to search for existing issues, and post patches fixing the issue. A mailing list does all of that, without having to deploy (and maintain and curate) a separate system.
Why do you think it's more difficult to report a bug this way, compared to a bug tracker? There's even a "report a bug" link on the project home page, where you can submit a bug report through a simple web form (you need a community account, but every other bug tracker I'm aware of requires that too).
Can you explain why you think a mailing list is less efficient than a bug tracker?
With a mailing list, I can work on the most recent problems, and with my memory, I can work on the problems that most stand out in my memory (either because they affect me personally, or the process of solving them has attracted my background attention). Neither of those seem like good ways to prioritize things.
But with a bug tracker, I can look for old problems that have not had attention paid to them, and pay attention to them.
I certainly agree a mailing list is a good approach, and many bug-tracking systems operate essentially around mailing lists: RT adds a tracking number to the subject line, and Debbugs essentially creates one mailing list per bug.
As an end-user the first thing I want to do before reporting a bug is search and see if it has already been reported or if it is being worked on and when it is expected to be released. If I was told that I had to dig through mailing list I would probably just stop before I even started.
> Can you explain why you think a mailing list is less efficient than a bug tracker?
As a bug reporter, I want a friendly way efficiently search and filter existing bugs based on status, version, subsystem, etc. I also want to be able to subscribe to a specific bug to get updates. Maybe you guys have some way to get all those features from a mailing list, but new users certainly won't have a clue.
As a developer I want to be able to easily tag, filter, assign and triage bugs. Assign priorities and associate them with releases and pull requests. I also want to be able to do high level reporting.