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 [email protected]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
