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

On 25 September 2015 at 11:32, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > I have frequently been the agent of change in matters of process, but I
> see
> > no useful change here, just lots of wasted time. But then why are we even
> > talking about change? What thing is broken that needs to be fixed? Why is
> > adopting a new package a fix for that?
>
> Fair questions indeed. I think the core points here are:
>
> 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.

> 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.

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

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.

I don't see a sustainable mechanism that can support the manpower resources
required to provide that information to those people, apart from become an
active contributor, or pay someone who is.

> I do not know how much emphasis the project should place on point #2.
> By definition, fixing that will not return any direct benefit to us.
> However, point #1 is clearly an issue and I think a low-overhead fix
> for it would be a good thing. If we can get some answer for #2 out
> of it at the same time, even better.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services