Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Yy3b7-00055F-3p for pgsql-hackers@arkaria.postgresql.org; Thu, 28 May 2015 19:36:09 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Yy3b6-00048A-K6 for pgsql-hackers@arkaria.postgresql.org; Thu, 28 May 2015 19:36:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Yy3b4-00045z-IY for pgsql-hackers@postgresql.org; Thu, 28 May 2015 19:36:06 +0000 Received: from tamriel.snowman.net ([2001:4830:167b::11]) by magus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1Yy3aw-00013O-Hv for pgsql-hackers@postgresql.org; Thu, 28 May 2015 19:36:05 +0000 Received: by tamriel.snowman.net (Postfix, from userid 1000) id DA0C95F7A1; Thu, 28 May 2015 15:35:56 -0400 (EDT) Date: Thu, 28 May 2015 15:35:56 -0400 From: Stephen Frost To: "Joshua D. Drake" Cc: pgsql-hackers Subject: Re: RFC: Remove contrib entirely Message-ID: <20150528193556.GH26667@tamriel.snowman.net> References: <55674016.80005@commandprompt.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rX4YkftDwxPGvzrT" Content-Disposition: inline In-Reply-To: <55674016.80005@commandprompt.com> X-Editor: Vim http://www.vim.org/ X-Info: http://www.snowman.net X-Operating-System: Linux/3.13.0-46-generic (x86_64) X-Uptime: 15:25:55 up 70 days, 1:14, 22 users, load average: 0.24, 0.14, 0.14 User-Agent: Mutt/1.5.21 (2010-09-15) X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org --rX4YkftDwxPGvzrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable JD, * Joshua D. Drake (jd@commandprompt.com) wrote: > Contrib according to the docs is: >=20 > "These include porting tools, analysis utilities, and plug-in > features that are not part of the core PostgreSQL system, mainly > because they address a limited audience or are too experimental to > be part of the main source tree. This does not preclude their > usefulness." We certainly seem to have moved on from that definition. If nothing else, it'd be valuable to clarify what contrib is and then rearrange things accordingly. > It has also been mentioned many times over the years that contrib is > a holding tank for technology that would hopefully be pushed into > core someday. I continue to feel this is a good use-case for contrib. > What I am suggesting: >=20 > 1. Analyze the current contrib modules for inclusion into -core. A > few of these are pretty obvious: >=20 > pg_stat_statements > citext > postgres_fdw > hstore > pg_crypto > [...] We don't really have a place in "-core" for them.. There has been ongoing discussion about that but nothing has changed in that regard, as far as I'm aware. We have moved a few things out of contrib and into bin, but that doesn't make sense for the above. What we would need for this is an 'extensions' directory, or similar, and a clear definition of what the requirements are around getting into it are. With that, we could decide for each module currently in contrib if it should go into the 'extensions' directory. I'm not sure that we would necessairly have to remove the contrib module or any modules which are deemed to not be appropriate for the 'extensions' directory. > I am sure there will be plenty of fun to be had with what should or > shouldn't be merged into core. I think if we argue about the > guidelines of how to analyze what should be in core versus the > merits of any particular module, life will be easier. Here are some > for a start: >=20 > A. Must have been in contrib for at least two releases > B. Must have visible community (and thus use case) I don't particularly like having a time-based requirement drive what's in which area, especially one that's double the length of our major release cycle. > 2. Push the rest out into a .Org project called contrib. Let those > who are interested in the technology work on them or use them. This > project since it is outside of core proper can work just like other > extension projects. Alternately, allow the maintainers push them > wherever they like (Landscape, Github, Savannah, git.postgresql.org > ...). That's an interesting idea, but it's unclear how this would be any different from PGXN..? Thanks! Stephen --rX4YkftDwxPGvzrT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJVZ24cAAoJEO1sijiDR2RVaLIQAL0bjTLkP4heAouD9F4nhC51 0wmwcaViW2XAfwJ+UNH6sSxboW+8qpgnp6Xvn4aV9jmq/M3LwvUfwn8ndQkPfRzI 0ax4wzRzBn+D1TYJRYl2bmOGk0otxS1KEHjDvT9XBPJJxC3ddmg/D/fZsfM2gUZ/ XrlvHD0hroLWYUjeCLPGZ6s/VUG6pRJpQEwUDaOWJfOBUnFdgq7KRKvbNX3Z+kA3 qHnDhCkdSAi1dV7U2jstijN8iz/+6RyDDNxy3HFKt0v4bfKtmuBCEG+xFV/4C/KA 381YGxVYU6OnL7f/VOYFJjpTLKAvzAQLg5SztjSDpSi13KNlOu5DEAZZfyKGmG0j uDcdKNrdpaD9KbDLWnJILHrzOX2F5c+oaSMNyxlph06VfrnNGtEUINNAucQnPLT+ lf+CZlKWqV1aZ/o1ADxhiKZG6wgRIN/VRBGcWMa25NBpBPhaPmMd7Mom0tjZAhKK klZCKvsv9cZiWVqd6tPIGorVZvdnJyB7s5JMOXosA5/sE+BCs1Y6Yo9Hws3bod77 i4lqUcQWw8YFAajCQGfc3c5U56ZP0y2WPHGBB6nBXG5wFuL2D60lA13aK7D9BJd8 PSZeNVLNKcyOI5SgsWFV81rcWOtwm4+KP0FScQzDdIQzzfEUZorVWDTzh5l7EPvk TEHu4yo1mmPb1TmGFJfu =uOhL -----END PGP SIGNATURE----- --rX4YkftDwxPGvzrT--