Re: contrib vs. gborg/pgfoundry for replication solutions - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: contrib vs. gborg/pgfoundry for replication solutions
Date
Msg-id 1082603935.80320.275.camel@jester
Whole thread Raw
In response to Re: contrib vs. gborg/pgfoundry for replication solutions  ("Marc G. Fournier" <scrappy@postgresql.org>)
List pgsql-hackers
> The point of projects.postgresql.org is that if someone *is* looking for
> an addon, they should be pointed to projects.postgresql.org ... if you try
> and merge everything into the -core distribution, you are either going to
> miss something that *someone* wants to use at some point, *or* one helluva
> large tar file to download ...

Sorry, here is where we're talking across each-other. I do NOT want
everything in one tarball. I do think it is reasonable to make a
simultaneous release (different tarballs) and inform the packagers how
to put dependencies between the items.

/usr/ports/x11/gnome is a completely empty package. It's only purpose is
to install a standard list of elements that an end user may wish to have
on their desktop. Those who have seen gnome before and know what it has
to offer avoid the "large" package and go straight to the guts
installing the specific applications they want (pulling in library
dependencies automatically).


I for see us maintaining a list of the applications we believe that a
new user may want. That list should be packaged up via the appropriate
methods (dependency list is most obvious) for beginners with PostgreSQL.

These applications would be visible on the main website with
documentation, direct download links, etc. They can make independent
releases on their own, but are required to keep up to -core development.

Advanced users go for the components they want. Beginners get a
reasonably complete set of tools so they can actually get started with
development.


It has much more to do with how things are perceived by the beginning
user than how they are actually implemented.




pgsql-hackers by date:

Previous
From: Karel Zak
Date:
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions
Next
From: Rod Taylor
Date:
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions