Re: Explicit psqlrc

Simon Riggs wrote:
> On Tue, 2010-07-20 at 09:05 -0400, Robert Haas wrote:
> > On Tue, Jul 20, 2010 at 8:21 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > > On Tue, 2010-07-20 at 07:49 -0400, Robert Haas wrote:
> > >> A further point is that it's very difficult to
> > >> keep track of progress if the CF page reflects a whole bunch of
> > >> supposedly "Waiting on Author" patches that are really quite
> > >> thoroughly dead.
> > >
> > > True, but the point under discussion is what to do if no reply is
> > > received from an author. That is something entirely different from a
> > > patch hitting a brick wall.
> > >
> > > We gain nothing by moving early on author-delay situations, so I suggest
> > > we don't.
> >
> > No, we gain something quite specific and tangible, namely, the
> > expectation that patch authors will stay on top of their patches if
> > they want them reviewed by the community. If that expectation doesn't
> > seem important to you, feel free to try running a CommitFest without
> > it. If you can make it work, I'll happily sign on.
>
> I don't think so. We can assume people wrote a patch because they want
> it included in Postgres. Bumping them doesn't help them or us, since
> there is always an issue other than wish-to-complete. Not everybody is
> able to commit time in the way we do and we should respect that better.
>
> Authors frequently have to wait a long time for a review; why should
> reviewers not be as patient as authors must be?
>
> We should be giving authors as much leeway as possible, or they may not
> come back.

By marking patches as 'returned with feedback' long before the end of
the commit-fest, we show feedback of how close we are to completing the
commit-fest. If we keep patches in limbo status, it is unclear how
close we are to CF completion. And, of course, the author can
reactivate the patch just by replying.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +