On 05/04/2012 09:03 AM, Robert Haas wrote:
I try pretty hard not to go off and do large amounts of work in a vacuum. If something is more than a couple days work, I post the design on hackers and wait for feedback before writing a line of code.
That is an excellent luxury to have. You've worked very hard to earn it. Not everyone is in the position where that's possible though.
Are you requesting more transparency in general, asking for my thoughts on logical replication specifically, or something else?
The straw man argument here would require 100% transparency on everything you do in regards to PostgreSQL and related software. Before doing any development on any code, first post here to ask for design review. And if someone asks you to work on a program that isn't open source from day one, refuse unless you can operate that transparently.
That standard is nice if you can pull it off. But I don't give you a hard time if you have to make some compromises from that ideal to keep yourself gainfully employed. You do a ton of good work for the PostgreSQL community in a transparent way, so I assume that you're doing the best you can. I would like to see that assumption presumed on our side, too.
Here are the individual straw men in this area I'd like to see put out of their misery:
"You're developing things in secret": if that's the case, we're pretty bad at it, given the history I outlined at http://archives.postgresql.org/message-id/4f9b1b6c.5010...@2ndquadrant.com
"That discussion didn't happen in the right place": it's not our fault that the cluster-hackers list exists. Go joust at getting that list shut down and their meeting during PGCon canceled if you think it's unproductive for discussions to happen there. I've been trying to bridge that gap for over two years now; note how many times I appear in the edit history at http://wiki.postgresql.org/index.php?title=ClusterFeatures&action=history
"You might do too much development in the wrong direction and not build the right thing": and? Yes, there are people who develop into a corner and end up doing unproductive work as a result. And there are others who submit things and give up when faced with feedback on them. Last time I checked, there wasn't anyone who flat-out rejects on-list feedback working for 2ndQuadrant. Instead, I see features that go through extensive and numerous review cycles based on what we hear back.
"Designs should be presented on-list before doing any development": this is not always practical for those of us who are doing feature development. Some feature sponsors are still getting used to open development. If we have a private development milestone date to hit *in order to get more funding for public PostgreSQL work*, which is often the case here, we try not to miss it. We'd be bad community members to do so. And sometimes that involves building a proof of concept or prototype here first, then submitting it to the community once it's moved onto being a proven concept. Since the community has a clear set of guidelines for how and when to submit new features, we make sure the development plans line up with them.
-- Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
