Re: RLS feature has been committed

From: Gregory Smith <gregsmithpgsql(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, 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 18:59:48
Message-ID: 5421C324.3080706@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/23/14, 9:00 AM, Andres Freund wrote:
> 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.

I haven't been doing much personal development work around here lately,
but I did more than a little of the planning on how to handle this as
responsibly as I felt it deserved. I think this is worth talking about
a little bit because this whole topic, how to deal with a funded project
where the committer is also a contributor, isn't something a lot of
people have visibility into. (Not talking about you, Andres, you know
the deal)

This commit didn't happen until I first succeeded in getting Stephen
Frost fully funded as a community PostgreSQL contributor (for this job,
as well as others with a broader community appeal). Everyone attached
to the budget side very explicitly understands that includes an
open-ended responsibility to the community for addressing fall-out from
RLS, going from unforeseen issues to revisiting the things left on the
known open items list. It's hard to reach perfect before commit;
eventually you just have to just shoot and see what happens.

Just to be really safe, I also kicked off training a whole new
PostgreSQL contributor (Adam Brightwell) five months ago, so that by the
time we got to here he's also making his own contributions to the
security code of the database. And that's included exercises tracking
down bugs in the early RLS POC deployments already going on here at
Crunchy, so that Stephen isn't the sole Postgres community expertise
bottleneck on the code even at this company. (I am NOT on the hook for
fixing RLS bugs)

The decision on when to commit was strictly Stephen's. During our last
chat, we agreed this seemed like an ideal time of year in the
development cycle for such a thing to land though. 9.5 is a fresh
branch, and there is plenty of time to clean up and/or revert if that's
the unfortunate end for anything going in today. Plus the ongoing
CommitFest schedule means everyone in the community already is arranging
to provide review resources needed in the near future pipeline.

I can understand that Robert feels a procedural sting and/or slight due
to the exact sequence of events here, and I'm staying out of that. But
in general, I don't know what we could have done much better to be a
responsible contributor, to finally push this long in development
feature over the finish line. A description like "rushing ahead" would
feel inappropriate to me for this one, given how much care went into
timing even roughly when this particular commit should happen. The time
of year in particular was very specifically aimed at for minimal
disruption, based on both major version release dates and the related
community development cycle around them.

--
Greg Smith greg(dot)smith(at)crunchydatasolutions(dot)com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-09-23 19:04:46 Re: BRIN indexes - TRAP: BadArgument
Previous Message Andres Freund 2014-09-23 18:24:22 Replication identifiers, take 3