Re: No Issue Tracker - Say it Ain't So!

On 09/25/2015 10:27 AM, Simon Riggs wrote:
> On 25 September 2015 at 11:32, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> 1. We don't have a good process for making sure things don't "slip
> through
> the cracks". I think everyone more or less relies on Bruce to run
> through
> his mailbox periodically and nag them about threads that don't seem to
> have been closed off. The deficiencies of that are obvious.
>
>
> I don't rely on that myself. That sounds like a personal viewpoint only.
> I welcome more discussion amongst Committers with regard to
> coordination, but formal systems aren't what I think will help there.
> That situation has recently improved anyway, so no further change needed
> at present, IMHO.

??? Improved how?

> 2. There's no visibility for outsiders as to what issues are open or
> recently fixed. Not being outsiders, I'm not sure that we are terribly
> well qualified to describe this problem precisely or identify a good
> solution --- but I grant that there's a problem there.
>
>
> If they can perform "git log" they can view what has happened recently.
> Tracking what might happen is much harder for active contributors.

It takes a lot of technical knowledge of PostgreSQL to relate a commit
message to a bug report, given that the bug report may not be
referenced, and the report and the commit often use completely different
terminology. Also, users are often wanting to look for bug fixes from
months or even years ago, and git log has crappy searchability.

I can't say how many times I've had a conversation like this:

"Oh, that's a known issue. It was fixed later in the 9.3 series."

"Really? In which release specificially?"

"Ummm.... lemme search the release notes ... I know it's here somewhere ..."

>
> I've never had a user ask me for such a list. All I here is compliments
> that our software is incredibly robust.

I have. I've had users ask for it, I've had customers ask for it, I've
had companies thinking of adopting PostgreSQL ask for it ... and for a
few of them, our lack of an issue tracker was a deciding factor in
saying that PostgreSQL "wasn't mature enough". Certainly it was major
points off when Forrester rated us.

Also, members of downstream projects would really like us to get a bug
tracker they can kick up bugs to if they're determined to be in
Postgres. There are bugs we're not even hearing about because it's too
confusing for someone who has a lot of projects to cover to figure out
our idiosyncratic system.

Today, having an issue tracker is considered "normal" for any
significant OSS project. The fact that we don't have one is regarded as
abberant, and not in a good way ... we're at the point where if we're
not going to adopt one, we'd better have a darned good reason which we
can explain clearly to the public.

> The only time this info is required is for people that provide a Support
> service based upon PostgreSQL, yet are not themselves sufficiently
> involved to know what bugs have been reported and are as yet unfixed. I
> expect such people are extremely interested in getting other people to
> do things that will help their business.

That has absolutely nothing to do with any reason for the PostgreSQL
project to have a bug tracker.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com