Re: RFC: Remove contrib entirely - Mailing list pgsql-hackers

From Neil Tiffin
Subject Re: RFC: Remove contrib entirely
Date
Msg-id DFF9DF5C-FFD4-4B18-BCE3-136A763A362C@neiltiffin.com
Whole thread Raw
In response to Re: RFC: Remove contrib entirely  ("David E. Wheeler" <david@justatheory.com>)
List pgsql-hackers
> On Jun 4, 2015, at 3:11 PM, David E. Wheeler <david@justatheory.com> wrote:
>
> On Jun 4, 2015, at 11:53 AM, Neil Tiffin <neilt@neiltiffin.com> wrote:
>
>> I have looked at PGXN and would never install anything from it.  Why?  Because it is impossible to tell, without
insideknowledge or a lot of work, what is actively maintained and tested, and what is an abandoned proof-of-concept or
idea.
>
> Well, you can see the last release dates for a basic idea of that sort of thing. Also the release status (stable,
unstable,testing). 
>
>> There is no indication of what versions of pg any of PGXN modules are tested on, or even if there are tests that can
berun to prove the module works correctly with a particular version of pg. 
>
> Yeah, I’ve been meaning to integrate http://pgxn-tester.org/ results for all modules, which would help with that. In
themeantime you can hit that site itself. Awesome work by Tomas Vondra. 
>
>> There are many modules that have not been updated for several years.  What is their status?  If they break is there
stillsomeone around to fix them or even cares about them?  If not, then why waste my time. 
>
> These are challenges to open-source software in general, and not specific to PGXN.

Of course, but the solution is having tools to easily determine the risk.  The fact that the modules pass or fail the
testson pgxn-tester is a significant step.  Knowing how long the module has been failing would be even better. 

>
>> So adding to Jim’s comment above, anything that vets or approves PGXN modules is, in my opinion, essentially
requiredto make PGXN useful for anything other than a scratchpad. 
>
> Most of the distributions on PGXN feature links to their source code repositories.
>
>> A big help would be to pull in the date of the last git commit in the module overview and ask the authors to edit
thereadme to add what major version of pg the author last tested or ran on. 
>
> That’s difficult to maintain; I used to do it for pgTAP, was too much work. pgxn-tester.org is a much better idea.

Yes it is.

Wow, that is awesome work (pgxn-tester.org).  Thanks Tomas Vondra, and David for pointing it out.  This improved my
opinionof PGXN significantly.  It might be helpful to at least put a link on the PGXN home page, beta or not, its
awesomeand even in beta it shows the future direction. 

It would be nice to see the development branch in the tests.  One project I am working on now targets 9.5.

It is important to know how long a stable module has been failing for a specific version of pg.  This is IMO a critical
measureof the level of support a module is receiving.  

Neil





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [CORE] Restore-reliability mode
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1