Explicit psqlrc
in [PgSql]
|
Prev: [PATCH] elimination of code duplication in DefineOpFamily()
Next: [HACKERS] trace_recovery_messages
From: Robert Haas on 20 Jul 2010 07:49 On Tue, Jul 20, 2010 at 7:41 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > So focus your effort by leaving this alone until the end of the CF. > Actively terminating things early doesn't help at all with the review > work you mention above, but it looks good if we are measuring "cases > resolved per day". Are we measuring that? If so, why? Who cares? We don't formally measure that, but yeah, I definitely keep an eye on it. I've found that if you don't keep a sharp eye on that, you end up not done with the CommitFest is supposed to be over. I'd much rather boot patches for reasonable justification throughout the CommitFest than boot everything at the end whether there's a justification or not. > Closing early gains us nothing, though might close the door on useful > work in progress. IMHO, closing early LOSES us nothing. People are free to work on their patches whenever they'd like, and hopefully will. But pretending we're going to review them all no matter when they get resubmitted just makes people grumpy when they find out that we're not magical and can't. 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. On the other hand, if this patch was really resubmitted already and I missed it, as you suggested, that's a whole different situation. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 20 Jul 2010 08:21 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. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 20 Jul 2010 09:05 On Tue, Jul 20, 2010 at 8:21 AM, Simon Riggs <simon(a)2ndquadrant.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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 20 Jul 2010 09:23 Robert Haas <robertmhaas(a)gmail.com> wrote: > 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. Barring some operational emergency here, I'll be reviewing the status of all the open patches in the CF today. If I can't find any new posting by the author for the patch in question, I'll mark it Returned With Feedback. I'll probably be cracking the whip on a few others, one way or another. If anyone wonders why I don't do so for certain patches, it will probably be because I've had off-list messages about needing more time to do a proper review or being in transit and unable to do more than post short emails at the moment. I do request that all authors and reviewers make an effort to keep the CF app page up-to-date. If you're not sure all recent patches, reviews, and significant comment posts are reflected in the app for a patch for which you're an author or reviewer, please check as soon as possible and make it right; it's save time for me and will help keep the process moving smoothly. Thanks, all. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 20 Jul 2010 09:34
On Tue, 2010-07-20 at 09:05 -0400, Robert Haas wrote: > On Tue, Jul 20, 2010 at 8:21 AM, Simon Riggs <simon(a)2ndquadrant.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. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |