From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, "Brightwell, Adam" <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Yeb Havinga <yeb(dot)havinga(at)portavita(dot)nl> |
Subject: | Re: RLS feature has been committed |
Date: | 2014-09-23 13:00:17 |
Message-ID: | 20140923130017.GB338@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-09-23 13:23:32 +0100, Dave Page wrote:
> Just to be clear here, the *only* issue we should even be discussing
> is whether the patch should or should not have been committed in the
> face of those objections. As Josh has also noted, the commitfest
> process was never meant to constrain what committers do or when they
> do it with their own patches or ones they've worked heavily on. They
> are there as a backstop to make sure that regardless of what the
> committers are doing day to day, patch authors know that their patch
> is expected to receive some review within N weeks.
FWIW, while not really at the core of the problem here, I don't think
this is entirely true anymore.
We certainly seem to to expect bigger feature patches to go through the
commitfest process to some degree. Just look at the discussions about
*committers* patches being committed or not at each cycles last
commitfest. Every single time the point in time they've been submitted
to which CF plays a rather prominent role in the discussion.
Also look at committers like Robert that *do* feel constrained about
when to commit or even expect review for submitted patches.
I think it's obvious that a committer doesn't need to wait till some
later commitfest to commit patches that have since gotten enough review
or are uncontroversial. Neither is the case here.
I also think committers need to be much more careful when committing
patches which they (or their employer) appear to have a business
interest in. Rushing ahead to commit the patch of somebody 'unrelated'
leaves a completely different taste than committing your colleagues
patch. *INDEPENDENT* of the actual reasons and the state of the patch.
Perhaps we can use this as a chance to make the review process a bit
better defined. There certainly have been a few patches by commiters
over the last years that have had a noticeable negative impact. Some of
which might have been cought by more diligent review.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-09-23 13:09:04 | Re: RLS feature has been committed |
Previous Message | Andres Freund | 2014-09-23 12:55:52 | Re: proposal: adding a GUC for BAS_BULKREAD strategy |