Re: RLS feature has been committed - Mailing list 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.smith@crunchydatasolutions.com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/