On Tue, Apr 10, 2012 at 8:12 PM, Robert Haas <robertmh...@gmail.com> wrote: > However exactly > the list turns out, there is no question that non-committers have been > quite successful in getting significant feature enhancements committed > in each of the last three releases, and I'm pretty confident it goes > back a lot further than that.
I agree that in practice non-committers do get a lot of great stuff done, but the question is if *more* stuff would get done if things were slightly different. To that end, I'd like to share my own anecdote on why I don't attempt large projects to Postgres at this time: I used to work on a proprietary postgres offspring and ship quite a bit of internals code. A couple of people I worked with are frequenters of this list, even. I spent nearly two years doing it, full time, without having to (or being able to) go through a full-blown community process from design to ship: I got a lot of nuts-and-bolts practice, and I really enjoyed it. Yet I don't take on large projects in the project now, and I'm even employed in a place where I could start doing that on-the-job. Why don't I? One reason I don't do that is because there is an unavoidable information asymmetry problem between myself and the committers. When I think of a committer and what makes me different than them, this is what I come up with: * More experience and expertise, both in general and with the project * Proven intent to maintain the work submitted by others for a long time. In a word, "stewardship" or "ownership" I'm grateful for both, but the latter point is one where some mind-reading is required: what's strategically important enough that's it is important enough to compromise on something? What compromises are acceptable? That is tantamount to guessing "what compromises is a committer willing to maintain?" And that can be a pretty personal thing and is hard to guess, and I don't think that's solvable as long as there seems to be this handoff from "the contributor" to "the project." It's hard to feel a sense of ownership -- and thus commitment -- if one cannot simply change one's own code, especially for trivia or churning around a future intent or purpose. If there is a bottleneck with the development process that is having a chilling effect on my ability to justify larger projects, it is this. I don't know what the most apparent way to optimize that bottleneck is, but there's my thoughts. I think part of the answer is more hooks, even if they come with reduced contracts in terms of maintenance (here this release, gone the next release), and less required justification to commit those; consider https://github.com/dimitri/pgextwlist, which relies on such a hook and is the only thing that makes 9.1's extension support viable for Heroku, yet is cohesive feeling with the rest of the system to the point that it pretty much goes unnoticed. That's a great property I wish I could see more of. Also, I am not able to spend as much time on large Postgres-projects because some of the tooling outside the database is still the weakest link in my chain for now, so the good news is that I've shifted my attention to projects that are very much related but not part postgres-proper. The point of having more hooks is to open up more opportunities for such tools without making the result feel incohesive and terrible for reasons not intrinsic to the idea it is trying to add (consider: using the statement hook in pgextwlist rather than preloaded security-definer UDFs that would run CREATE EXTENSION for you. Yuck.) -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
