On 7 April 2012 23:51, Tom Lane <tgl@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
