On 7 April 2012 23:51, Tom Lane <t...@sss.pgh.pa.us> wrote: > As for the steering committee, core tries hard not to make technical > decisions for the project; it's better to let those emerge by consensus.
I don't really consider this to be an engineering problem, which is precisely why I bring up the role of core here. Holding up a release for a feature has costs (the feature is delayed, which in some way hurts us, as our users don't have a new release for that much longer, etc) and benefits (when the release is available, Postgres is that much better one release sooner). Naturally, the maturity of the existing code, as judged by the community, would be heavily weighed in this process, but the wider importance of the feature, and how much of an advantage having it earlier provides, would also be weighed. Open source products (as distinct from projects) often have this sort of cost-benefit analysis made by individuals who are somewhat removed from the engineering decisions themselves. While I'm certainly not advocating that we switch to that model - in particular, I am not advocating anything less than full transparency - surely there is something to be said for some aspects of it, mostly to break the sorts of deadlocks that can sometimes occur. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
