Paul Ramsey writes:
> Perhaps we could back up at this point and revisit 'contrib' ... at what
> point in the size/licence/redundace spectrum do we become reasonable
> candidates for 'contrib', if ever? The current tenor seems to be that at
> 600K/GPL/point-line-polygon we are "too big"/"too restrictive and/or too
> free"/"overlapping". Would moving on any of those axes be sufficient, or
> do we have to address all three (practically speaking, I not think there
> is anything to be done about size).
Historically, contrib was the place for small pieces of code that a)
could/would/should not go into the core for some reason, b) were
unreasonable to distribute otherwise (too small, not general enough), and
c) served as examples of how to use the type/functione extension features.
You satisfy a), you do not satisfy b), and I doubt that c) is still
applicable.
Projects that are as organized, professional, and value-adding as yours is
can surely stand on their own. I compare this to the recently released
OpenFTS. If we start including projects of this size we'd explode in size
and maintenance overhead.
I don't want to make the impression that I don't like you guys. It's just
that we have to realize that there is a *lot* of coding using PostgreSQL
these days, and it's unreasonable to include all of this in our
distribution, while at the other end people are crying about removing the
documentation from the tarball because it's too big already.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
