FWIW that's a list of "open items" for PostgreSQL 10 release. So it's not really a "global" authoritative list of open issues, but something the project uses to make sure we deal with all known issues in the development version before the first release.
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).
Wow, this surprises me a lot, especially combined with the consensus position that Postgres is good, robust software. What is Postgres doing right and how can other projects follow their lead?
On a more serious note, what makes Postgres so reliable is a number of things. For example:
* 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.
Was Postgres always this way? Was the code from Berkeley abnormally stable/robust for commercial software (and extremely abnormally stable/robust for academic software), or was there an effort to clean it up to get to high quality?
That seems like a bit of a false dichotomy. Do the Postgres Devs genuinely see having a bug tracker as a "bad thing"? Or are they just stuck in their ways at this point?
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
Well, it was not really meant entirely seriously, of course.
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?
A good bug tracker makes it easier to track status and priority. The ironic thing about the blog post is that it is certainly possible there is a 14.5 year old bug in Postgres, but how would you know? Who is going to go look at 14.5 year old bug report emails and try to figure out if any of them are still open?
Contra: A 14.5 year old open issue that is genuinely untouched for 14.5 years is most likely irrelevant, either because it was swept up, has become obsolete or is some kind of request that no one cares about (otherwise it would not sit around untouched for 14.5 years).
One thing a bug tracker solves for me is, I have some time to work on things, what should I work on? (This is a different search problem from, I think I'm having this bug, has anyone else had it?)
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.
> Why do you think it's more difficult to report a bug this way, compared to a bug tracker?
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.
This seems to be the canonical list.