Tom Lane <t...@sss.pgh.pa.us> writes: > Sure, but that's a documentation issue, which again is not going to be > helped by a source-tree rearrangement.
So we have several problem to solve here, and I agree that source code rearrangement is fixing none of them. Maybe it would ease maintaining down the road, though, but I'll leave that choice up to you. Which contribs are ready (safe) for production? We could handle that in the version numbers, having most of contrib at version 0.9.1 (say) and some of them at version 1.0. We could also stop distributing examples in binary form, only ship them in source package. Then we need to include inspection extensions into the core packaging, but still as extensions. That's more of a packager problem, except that they need a clear and strong message about it. Maybe have a new Makefile and build those extensions as part of the server build, and install them as part as the "normal" install. Another mix of those ideas is to ship inspection extensions and ready for production ones all into a new package postgresql-server-extensions that the main server would depend on, and the ones that are adding more dependencies still in contrib, where not-ready for production extensions would not get built. This kind of ideas would also allow to quite easily remove things from the main server and have them as extensions, available on any install but a CREATE EXTENSION (WITH SCHEMA pg_catalog) command away. And still maintained at the same quality level in the source tree. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers