Josh Berkus wrote:
> Thomas Hallgren wrote:
>> A user would probably rather see criterion's like
>> feature richness and standards conformant. These problems persist
>> although a number of actors bundle PostgreSQL with various modules
>> today.
>
> What you're talking about is creating a "distribution" of PostgreSQL
> in the same way that there are distributions of Linux.
> Traditionally, we've left this to commercial distributors, and
> OS packagers of PostgreSQL to do this. Other people have
> explained this strategy on this thread.
There is an element of "code centric-ness" in this whole argument which
inverts the order of operations involved in coming to know and
understand a project from the outside.
If we want PostgreSQL to "look bigger" from the outside, it is not
necessary to actually *make* it bigger, "looking" bigger is sufficient.
Imagine a download page that included:
postgresql-database-8.1.4
postgresql-replication-1.0.2
postgresql-gis-1.1.3
postgresql-pooling-1.0.3
Hey, the postgresql database has replication, a spatial extension, a
connection pooler, and everything! What a slick project!
And, hopefully, when I went to the documentation page, I would find a
similar split:
PostgreSQL Database Documentation
PostgreSQL Replication Documentation
PostgreSQL GIS Documentation
And so on.
It does not require rolling a larger distribution, just making all the
components available from one place. Perhaps some cajoling, etc, to get
the components to follow some documentation standards so that integrated
documentation is possible. Maybe some cajoling to get things named in a
boring generic way as the examples above.
All the bits are there, they don't need to be *put* together, just
*presented* together. People can put them together themselves relatively
easily, given the right documentation.
Paul
PS - Which is not to say I am volunteering, it's still more work than
just maintaining the core pages, but it is at least largely restricted
to web site activities, not code activities.
