[postgis-users] The first release of the PostGIS Add-ons is out!

Stephen Woodbridge woodbri at swoodbridge.com
Mon Nov 18 12:33:18 PST 2013


On 11/18/2013 2:53 PM, Pierre Racine wrote:
> Thanks Stephen for these suggestions,
>
>> Rather than try to be the aggregator of the code submissions, we
>> decided to become an index for them. We created a wiki page that
>> would allow people to place a short description of what they
>> provide and a link to github gist or project.
>
> So they are not integrated into the main package? That the point of
> the Add-ons: To integrate all of them into a single, simple to
> install and document file.

Correct and I understand that need also. Our thought on this is that we 
can pick and choose which 3rd party function we think fit best into a 
broader set of users in the community and those then become candidates 
for integration.

What had happened in the past is that everyone tossed in various 
functions that they thought would be useful but due to lack of 
ownership, standards, documentation, and most of all testing, we ended 
up with a bunch of useless function most of which didn't work and only 
provided a spring board for somebody that needed a similar function to 
clone and maintain in their own environment.

Using gists and or index, we hope to provide good examples the 3rd 
parties have written, but without all the headache of bad files in the 
release. It is a work in progress. When I write a new function I have to 
continually ask myself, should this be a gist or part of core. What 
seems to be evolving is the simple utility functions that 80% of the 
users might need should be core and more complex "application" level 
stuff should probably be a gist.

>> This puts more of the responsibility of the submitter to document
>> and maintain the submission because it is theirs and reflects on
>> them, but has the advantage to the community that it is easy to
>> find the links that are relevant to the pgRouting community. It
>> also has the advantage that we only need to maintain the index and
>> that issues and problems get reported directly to the submitter
>> rather than to us because we are hosting it.
>>
>> A different approach but you might find it advantageous to migrate
>> to something loser to this model for what you are trying to
>> provide.
>
> One thing that make those Add-ons a bit different I think is that all
> the provided functions should not really be related to each other.
> They should hence come little by little, so easier to integrate, and
> there will be no need for a whole consistent documentation. If
> someone want to release a specialized set of function (like
> pgRouting) then should think about developing their own extensions as
> you did.

yes, again simple utility functions that are widely useable and easy to 
maintain, test and document are more like to become core. Big complex 
things with a few excepts should probably remain as gists.

> I think (I might be wrong) progressively integrating new functions as
> GitHub pull requests should not be too much work. I will try to
> enforce the rules I provide at the beginning of the file before
> accepting any submission.

yes, it is trivial to pull in gists or pull requests.

-Steve

> Pierre
>
>
> _______________________________________________ postgis-users mailing
> list postgis-users at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>



More information about the postgis-users mailing list