Robert Haas wrote > It's difficult to imagine a more flagrant violation of process than > committing a patch without any warning and without even *commenting* > on the fact that clear objections to commit were made on a public > mailing list. If that is allowed to stand, what can we assume other > than that Stephen, at least, has a blank check to change anything he > wants, any time he wants, with no veto possible from anyone else?
I'm of a mind to agree that this shouldn't have been committed...but I'm not seeing where Stephen has done sufficient wrong to justify crucifixion. Especially since everything is being done publicly and you are one of the many people in the position to flex a veto by reverting the patch. I see this like a black swan event[1]: needs to be addressed, is thought provoking, but ultimately shouldn't be treated as something to overreact to until it happens more frequently. There are enough checks-and-balances when it comes to committed code - which in this case is during pre-beta development - that one should simply allow for a certain level human fallacy to creep in and need periodic addressing/correcting. At this point my hindsight says a strictly declaratory statement of "reasons this is not ready" combined with reverting the patch would have been sufficient; or even just a "I am going to revert this for these reasons" post. The difference between building support for a revert and gathering a mob is a pretty thin line. Subsequent, possibly private, discussion between you and Stephen could then occur before making any conclusions you form public so that others can learn from the experience and ponder whether anything could be changed to mitigate such situations in the future. Though I guess if you indeed feel that his actions were truly heinous you should also then put forth the proposal that his ability to commit be revoked. If your not willing to go to that extent then, unless you know Stephen personally, I'd not assume that public flogging is the best way to get him to not mess up in the future; but the honest and cordial dialog about cause/effect is likely to be more productive and less self-destructing. Though, to each their own style. As a committer you have a responsibility to work not only with code but with those who write the code; and while I myself am not a particularly strong (or experienced) manager I have enough life experience to give opinions on leadership. I won't fault you for being yourself but simply put forth my own impressions and some ideas to provoke thought. I'm also not the one whose efforts were marginalized so don't have the same emotional attachment to the situation as you do - an attachment that needs to be recognized because, as I do know from experience, even when you are right and justified an overreaction makes you come off unfavorably and doesn't materially improve the situation beyond what it could have been otherwise. David J. 1. http://en.wikipedia.org/wiki/Black_swan_theory -- View this message in context: http://postgresql.1045698.n5.nabble.com/RLS-feature-has-been-committed-tp5819983p5820020.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers