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/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
