On 25 September 2015 at 11:32, Tom Lane <t...@sss.pgh.pa.us> wrote:

> Simon Riggs <si...@2ndquadrant.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/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Reply via email to