contrib vs. gborg/pgfoundry for replication solutions

Hello,

My personal opinion is that contrib should be removed entirely. Just
have a contrib.txt that says all contrib modules are at pgfoundry or
whatever.

Sincerely,

Joshua D. Drake

Jan Wieck wrote:

Jan Wieck wrote:

Taking into account that quite a few people have repeatedly stated that
the components in contrib are considered more supported/recommended than
similar solutions found on gborg or any other external site, I suggest
we move the projects dbmirror and dblink to gborg. The rserv contrib
module seems to me to be an early Perl prototype of erserver, nobody is
working on any more. I suggest we drop that entirely.

Comments/alternatives?

Agreed.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Joshua D. Drake wrote:

Hello,

My personal opinion is that contrib should be removed entirely. Just
have a contrib.txt that says all contrib modules are at pgfoundry or
whatever.

I'm not so sure that's a good idea. I think contrib is a good
repository for code that is tightly tied to the backend, or provides
extentions to the backen, or is something that will eventually be
integrated into the backend, but just isn't ready for prime time yet
(pg_autovacuum for example). The value of contrib is exposure. I
firmly believe that pg_autovacuum would not have gotten as much testing
from gborg as it has from contrib.

Perhaps the definition of what should be in contrib should be tightened
down, and anything that doesn't meet that definition should be removed,
but I think contrib is a good concept.

Matthew

"Joshua D. Drake" <jd@commandprompt.com> writes:

My personal opinion is that contrib should be removed entirely.

That's not real workable for code that is tightly tied to the backend,
such as the various GIST index extensions presently in contrib. It's
just easier to maintain that code when it's in with the backend.

However the replication modules don't seem to have such a linkage,
so I have no objection to moving them out.

regards, tom lane

-----Original Message-----
From: Joshua D. Drake [mailto:jd@commandprompt.com]
Sent: 21 April 2004 19:16
To: Jan Wieck
Cc: PostgreSQL-development
Subject: Re: [HACKERS] contrib vs. gborg/pgfoundry for
replication solutions

Hello,

My personal opinion is that contrib should be removed
entirely. Just have a contrib.txt that says all contrib
modules are at pgfoundry or whatever.

Couldn't agree more.

Regards, Dave.

On Wed, 21 Apr 2004, Tom Lane wrote:

"Joshua D. Drake" <jd@commandprompt.com> writes:

My personal opinion is that contrib should be removed entirely.

That's not real workable for code that is tightly tied to the backend,
such as the various GIST index extensions presently in contrib. It's
just easier to maintain that code when it's in with the backend.

However the replication modules don't seem to have such a linkage,
so I have no objection to moving them out.

Agreed ... but I also think that something like pg_autovacuum should be
moved to gborg ... there seems to be alot of activity on fixing bugs in it
that most ppl won't see until they upgrade to the next release, even
though those fixes would be pertinent/useful to their current
implementation ... begin able to download/install pg_autovacuum 1.1 would
definitely be a good thing, when it was considered stable enoguh for a
release ...

tsearch, I believe, is maintained somewhere else already, no? same with
tsearch2?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

tsearch, I believe, is maintained somewhere else already, no? same with
tsearch2?

Yes that is correct but I think they commit back to contrib before they
release.

Realistically, although I did not used to agree, I believe that the only
that that should come with PostgreSQL is PostgreSQL and required items
for PostgreSQL.

IMHO: PostgreSQL should include:

PostgreSQL
Psql
All development headers
C/C++ Libs

Everything else should be on SourceForge or Gforge or whatever. The
possible exception would be the pl stuff.

Sincerely,

Joshua D. Drake

"Marc G. Fournier" <scrappy@postgresql.org> writes:

On Wed, 21 Apr 2004, Tom Lane wrote:

"Joshua D. Drake" <jd@commandprompt.com> writes:

My personal opinion is that contrib should be removed entirely.

That's not real workable for code that is tightly tied to the backend,
such as the various GIST index extensions presently in contrib. It's
just easier to maintain that code when it's in with the backend.

tsearch, I believe, is maintained somewhere else already, no? same with
tsearch2?

No, those guys are exactly the sort of backend-dependent code I'm
thinking of. Teodor just recently made a GIST API change that affected
both the core backend and tsearch (as well as the other GIST modules in
contrib). With separate distribution trees that would've been a lot
more painful to do.

I think the long-term plan for tsearch2, at least, should be full
integration rather than separation ...

regards, tom lane

I almost agree, but I think things that are being actively developed to
eventually move into the backend, like autovacuum or slony-I should be in
contrib. Things that aren't destined for backend integration should be
removed though, like pgbench or dblink or whatnot.

On Wed, 21 Apr 2004, Joshua D. Drake wrote:

Joe Conway wrote:

Jan Wieck wrote:

Taking into account that quite a few people have repeatedly stated that
the components in contrib are considered more supported/recommended than
similar solutions found on gborg or any other external site, I suggest
we move the projects dbmirror and dblink to gborg. The rserv contrib
module seems to me to be an early Perl prototype of erserver, nobody is
working on any more. I suggest we drop that entirely.

Comments/alternatives?

dblink gets regularly updated as and when things change which affect it
in the backend. It is more tightly bond to the backend than a client
application, which the replication solutions you mention are. It is not
a replication solution anyway, so I'm not sure why you would categorize
in that way.

None of the replication solutions I see are client applications only.
Substantial parts of erserver and Slony for example are loadable modules
and stored procedures, tightly bond to the backend by using data and
functionality not available via the SPI. So the same problems apply
here, which then would be a reason to add them to contrib as well?

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

The problem with moving all contribs to gborg is that sometimes it's
required to change many modules, for example, because of changing
GiST interface. Tom saves a lot of working for contrib authors, when he
change code in core. I'm not sure, gborg would provide easy access for
such kind of things. tsearch2, particularly, is maintained in pgsql CVS.

Oleg
On Wed, 21 Apr 2004, Joshua D. Drake wrote:

tsearch, I believe, is maintained somewhere else already, no? same with
tsearch2?

Yes that is correct but I think they commit back to contrib before they
release.

Realistically, although I did not used to agree, I believe that the only
that that should come with PostgreSQL is PostgreSQL and required items
for PostgreSQL.

IMHO: PostgreSQL should include:

PostgreSQL
Psql
All development headers
C/C++ Libs

Everything else should be on SourceForge or Gforge or whatever. The
possible exception would be the pl stuff.

Sincerely,

Joshua D. Drake

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

Hello,

Well perhaps we can have exceptions. TSearch would be a good exception
as it really should be integrated into PostgreSQL anyway.

There are very few of these that I think would be an issue.

Sincerely,

Joshua D. Drake

Oleg Bartunov wrote:

IMHO it's not all that important where the source is developed (core
cvs, gborg etc) - whichever suits the development/release model best
shuold be used (meaning inside core only if it should be released on the
very same schedule as the main backend only).

What is more important is the exposure of the released versions. I think
it should be possible (and fairly easy) for projects developed outside
the core to get included in the "official download page", meaning go on
the ftp site and mirrors. Today it seems ODBC and pgadmin3 go there, but
pretty much nothing else (not even JDBC?). Perhaps a good structure
there would allow more proejcts to get that kind of exposure, and be
easier to find.

I quite often get people who claim "there is no this or that" for pgsql
when it's on gborg - simply becauase they didn't find it on the ftp
site. If you go looking, you'll find it on gborg, but if you don't know
where to look it can be hard. Especially for newcomers.

//Magnus

People:

I almost agree, but I think things that are being actively developed to
eventually move into the backend, like autovacuum or slony-I should be in
contrib.  Things that aren't destined for backend integration should be
removed though, like pgbench or dblink or whatnot.

I agree with this. Although I point out that, per Jan, Slony does *not* fall
in this group.

From my perspective, there are 2 criteria for something being in Contrib:

1) is the module tightly tied to particular versions of PostgreSQL, so that
the version shipped with 7.4 would not work with 7.5 or with 7.3?

2) Is the module being considered for eventual incorporation into the
mainstream backend?

That being said, let us get projects.postgresql.org up and running first ...
we've hit some technical snags today.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

On Wed, 21 Apr 2004, Tom Lane wrote:

No, those guys are exactly the sort of backend-dependent code I'm
thinking of. Teodor just recently made a GIST API change that affected
both the core backend and tsearch (as well as the other GIST modules in
contrib). With separate distribution trees that would've been a lot
more painful to do.

I think the long-term plan for tsearch2, at least, should be full
integration rather than separation ...

But there should be some sort of path to full integration ...
isdb_ibbn(sp?) has been there forever, and I canj't see it ever being
integrated ...

Personally, the neat thing about PostgreSQL is that we are extendible(sp?)
quite easily, and stuff like tsearch, earthdistance, postgis, etc all show
that very nicely ... why add for the sake of adding?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

On Wed, 21 Apr 2004, scott.marlowe wrote:

I almost agree, but I think things that are being actively developed to
eventually move into the backend, like autovacuum or slony-I should be in
contrib. Things that aren't destined for backend integration should be
removed though, like pgbench or dblink or whatnot.

Slony-I involves no backend integration that I've seen in its docs ...
Jan? Did I miss something?

As far as stuff like autovacuum, though ... its something that could
definitely benefit from a seperate release cycle from the main code ...

Has anyone looked at developing an Installer/packaging system so that as
far as the code is concerned, thing are seperate projects, but for the end
user ...

The thing is, for how many ppl are seperate packages difficult? I know
for me, under FreeBSD, I cd to a /usr/ports/databases/pg_autovacuum and
type 'make install' and its done ... I thought that stuff like Redhat had
the full screen installer that lists things?

My point is that all of this stuff shouldn't be in the core CVS ... its a
packaging issue, not a cvs one ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

On Wed, 21 Apr 2004, Jan Wieck wrote:

Joe Conway wrote:

Jan Wieck wrote:

Taking into account that quite a few people have repeatedly stated that
the components in contrib are considered more supported/recommended than
similar solutions found on gborg or any other external site, I suggest
we move the projects dbmirror and dblink to gborg. The rserv contrib
module seems to me to be an early Perl prototype of erserver, nobody is
working on any more. I suggest we drop that entirely.

Comments/alternatives?

dblink gets regularly updated as and when things change which affect it
in the backend. It is more tightly bond to the backend than a client
application, which the replication solutions you mention are. It is not
a replication solution anyway, so I'm not sure why you would categorize
in that way.

None of the replication solutions I see are client applications only.
Substantial parts of erserver and Slony for example are loadable modules
and stored procedures, tightly bond to the backend by using data and
functionality not available via the SPI. So the same problems apply
here, which then would be a reason to add them to contrib as well?

Why is it the core developers responsibility to make sure that an
application stays in sync with the main tree? Personally, that is giving
life to software that could just as easily be unused by anyone, but kept
in the code base because "a commit was made to it less then 6 months ago"
...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

On Thu, 22 Apr 2004, Magnus Hagander wrote:

IMHO it's not all that important where the source is developed (core
cvs, gborg etc) - whichever suits the development/release model best
shuold be used (meaning inside core only if it should be released on the
very same schedule as the main backend only).

What is more important is the exposure of the released versions. I think
it should be possible (and fairly easy) for projects developed outside
the core to get included in the "official download page", meaning go on
the ftp site and mirrors. Today it seems ODBC and pgadmin3 go there, but
pretty much nothing else (not even JDBC?). Perhaps a good structure
there would allow more proejcts to get that kind of exposure, and be
easier to find.

I see no reaosn why projects can't be mirrored into the main ftp server,
and brought through the mirrors ...

I quite often get people who claim "there is no this or that" for pgsql
when it's on gborg - simply becauase they didn't find it on the ftp
site. If you go looking, you'll find it on gborg, but if you don't know
where to look it can be hard. Especially for newcomers.

ftp://gborg.postgresql.org/pub - ls everything is listed there ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

The thing is, for how many ppl are seperate packages difficult? I know
for me, under FreeBSD, I cd to a /usr/ports/databases/pg_autovacuum and
type 'make install' and its done ... I thought that stuff like Redhat had
the full screen installer that lists things?

Well, if setup correctly for redhat, debian or even SuSE you would type:

apt-get install pg_autovacuum

or with redhat you might also do

yum install pg_autovacuum

But that is packaging and that is up to the developers of the particular
project.

Joshua D. Drake

Marc G. Fournier wrote:

On Wed, 21 Apr 2004, scott.marlowe wrote:

I almost agree, but I think things that are being actively developed to
eventually move into the backend, like autovacuum or slony-I should be in
contrib. Things that aren't destined for backend integration should be
removed though, like pgbench or dblink or whatnot.

Slony-I involves no backend integration that I've seen in its docs ...
Jan? Did I miss something?

Slony-I is intended to be PG version independent as much as possible. It
would rather hurt to move it into contrib. Sure are there backend
dependencies to #ifdef/#else, but for Slony-I this is considered a
strength, not a problem. How else would it be possible to use Slony-I to
do a PostgreSQL major version upgrade of multi-GB databases with only a
few seconds interruption?

As far as stuff like autovacuum, though ... its something that could
definitely benefit from a seperate release cycle from the main code ...

Has anyone looked at developing an Installer/packaging system so that as
far as the code is concerned, thing are seperate projects, but for the end
user ...

The thing is, for how many ppl are seperate packages difficult? I know
for me, under FreeBSD, I cd to a /usr/ports/databases/pg_autovacuum and
type 'make install' and its done ... I thought that stuff like Redhat had
the full screen installer that lists things?

I think most of the current contrib projects are more missing the
advantage version independence would have for the ease of "sitting" in
contrib and having the whole project management around them just done.
Yes, doing your own gborg project costs time. You have to maintain
pages, do your own release cycles with announcement, BETA phase,
tarballs, packaging and all the nine yards. Being in contrib avoids all
that in a very convenient way.

My point is that all of this stuff shouldn't be in the core CVS ... its a
packaging issue, not a cvs one ...

Exactly.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

I think most of the current contrib projects are more missing the
advantage version independence would have for the ease of "sitting" in
contrib and having the whole project management around them just done.
Yes, doing your own gborg project costs time. You have to maintain
pages, do your own release cycles with announcement, BETA phase,
tarballs, packaging and all the nine yards. Being in contrib avoids all
that in a very convenient way.

I think Gnome (and KDE) have the right idea. Several independent small
projects that once or twice a year get together and have a big release.

We could co-ordinate a set of projects (phppgadmin, pgadmin, slony,
jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL.

We then setup several 'meta' packages. For example, PostgreSQL-lite
might be just the core. PostgreSQL-Advanced might include jdbc, pgadmin,
slony, tsearch, postgis and everything in postgresql-lite.

Those who know what they want would be free to install the individual
packages just like with Gnome you can install epiphany and it'll pull in
everything needed for it without any extras.

I suppose one trick is allowing things like Postgis to be compiled
without requiring the source code to be around -- although I suppose we
could suggest a postgresql-headers package which Mozilla did that for a
while.

On Wed, 21 Apr 2004, Rod Taylor wrote:

I think most of the current contrib projects are more missing the
advantage version independence would have for the ease of "sitting" in
contrib and having the whole project management around them just done.
Yes, doing your own gborg project costs time. You have to maintain
pages, do your own release cycles with announcement, BETA phase,
tarballs, packaging and all the nine yards. Being in contrib avoids all
that in a very convenient way.

I think Gnome (and KDE) have the right idea. Several independent small
projects that once or twice a year get together and have a big release.

We could co-ordinate a set of projects (phppgadmin, pgadmin, slony,
jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL.

We then setup several 'meta' packages. For example, PostgreSQL-lite
might be just the core. PostgreSQL-Advanced might include jdbc, pgadmin,
slony, tsearch, postgis and everything in postgresql-lite.

I'd like to agree with this concept, but it falls way short of addressing
the problem ... and the problem isn't even pulling things out of contrib
... there are alot of good projects out there that aren't on gforge or in
the core distribution that ppl just aren't finding ...

a 'Meta Package' doesn't help much, since unless you put *everything* into
it that you can possibly find, there is always going to be something
missing that someone would find useful ... and if you put everything into
it, most ppl would only use a small percentage of what is there ...

People keep focusing on how to make a super-meta package ... the problem
isn't making one big package that contains it all, it is making sure that
what is available is easy to find ... what we need is something like
freshmeat that is *only* postgresql software ...

Now, Josh et al is working on finishing touches of he Projects web site
... I don't know everything that its able to do, but it does provide a
centralized, PostgreSQL specific, place to go to see what is available, as
long as ppl use it.

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Magnus Hagander wrote:

IMHO it's not all that important where the source is developed (core
cvs, gborg etc) - whichever suits the development/release model best
shuold be used (meaning inside core only if it should be released on the
very same schedule as the main backend only).

What is more important is the exposure of the released versions. I think
it should be possible (and fairly easy) for projects developed outside
the core to get included in the "official download page", meaning go on
the ftp site and mirrors. Today it seems ODBC and pgadmin3 go there, but
pretty much nothing else (not even JDBC?). Perhaps a good structure
there would allow more proejcts to get that kind of exposure, and be
easier to find.

I quite often get people who claim "there is no this or that" for pgsql
when it's on gborg - simply becauase they didn't find it on the ftp
site. If you go looking, you'll find it on gborg, but if you don't know
where to look it can be hard. Especially for newcomers.

I was thinking about CPAN. They have download stuff, but it installs
very easily. I wonder if we should allow gborg projects to interface to
our configure output in a way that makes it easier for them to be
installed.

The gborg is easy for development and releasing, but loses in the
easy-of-use category sometimes.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Marc G. Fournier wrote:

Why is it the core developers responsibility to make sure that an
application stays in sync with the main tree? Personally, that is giving
life to software that could just as easily be unused by anyone, but kept
in the code base because "a commit was made to it less then 6 months ago"
...

Well, in the case of dblink, consider this:

- It is used by a fair number of people -- questions are answered on the
lists at least once a week with "see contrib/dblink".

- It is dependent on backend code to the extent that it cannot be built
outside of the contrib folder, unless some backend code is duplicated
in the external project. It also has no build system of its own.

- dblink-type capability should someday make it into the backend, albeit
in the form of something compliant to the SQL/MED spec. This is
standard functionality in many of the RDBMSs that Postgres users
migrate from, and it is needed by enterprise users.

- The maintenance burden on core developers is pretty minimal. Recent
examples of where it was touched due to other changes in the backend
are:

* Tom - sort_mem to work_mem change
* me - elog to ereport change
* Neil - change to tuplestore_begin_heap declaration

These changes were part of the routine "grep for all the affected
code for the change I'm making", hence almost free (at least in my
opinion, I'll let Tom or Neil object if they feel otherwise).

Had dblink been on gborg, they (Tom and Neil) never would have seen that
their backend change affected it. It might have been weeks or months
before anyone noticed that it no longer worked against cvs tip (possibly
during beta for the next release). At that point the effort involved in
figuring out why it no longer works, while not huge, is certainly not as
small as the change-as-you-go approach we have now. I deal with this
very issue for PL/R. I have to pay close attention to commit messages or
I get bitten.

These same arguments apply to other things in contrib, and probably
could apply to some that currently are not.

In any case, I don't understand what the driver is to kill contrib. I
fully agree that it should be maintained (meaning that someone other
than core is interested enough to provide patches if non-trivial
maintenance is required to keep it compiling), and stuff that is not
used or suitably licensed should be removed. The contrib build system
ought to be maintained in working order in any case because it makes it
far easier to extend Postgres with your own functions.

Anyway, just my 2cents.

Joe

On Wed, 2004-04-21 at 21:29, Marc G. Fournier wrote:

On Wed, 21 Apr 2004, Rod Taylor wrote:

I think most of the current contrib projects are more missing the
advantage version independence would have for the ease of "sitting" in
contrib and having the whole project management around them just done.
Yes, doing your own gborg project costs time. You have to maintain
pages, do your own release cycles with announcement, BETA phase,
tarballs, packaging and all the nine yards. Being in contrib avoids all
that in a very convenient way.

I think Gnome (and KDE) have the right idea. Several independent small
projects that once or twice a year get together and have a big release.

We could co-ordinate a set of projects (phppgadmin, pgadmin, slony,
jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL.

We then setup several 'meta' packages. For example, PostgreSQL-lite
might be just the core. PostgreSQL-Advanced might include jdbc, pgadmin,
slony, tsearch, postgis and everything in postgresql-lite.

I'd like to agree with this concept, but it falls way short of addressing
the problem ... and the problem isn't even pulling things out of contrib
... there are alot of good projects out there that aren't on gforge or in
the core distribution that ppl just aren't finding ...

a 'Meta Package' doesn't help much, since unless you put *everything* into
it that you can possibly find, there is always going to be something
missing that someone would find useful ... and if you put everything into
it, most ppl would only use a small percentage of what is there ...

We have the current issue of people not knowing that projects like
pgadmin exist or where to find the jdbc drivers.

These basic components (and others a large segment uses that are well
maintained) should go through a release cycle with the -core including
the platform test/report phase and be prominently listed in the
downloads area and documentation areas -- just as we do for PostgreSQL
proper.

Goto http://postgresql.org, now track down the jdbc drivers or how to
use them. To a significant portion of our users this is more important
than CREATE FUNCTION is and in 7.5 jdbc documentation will be much more
difficult to find, but no less important than it used to be.

Another issue is organizing the hundreds of addon programs that do
everything from parsing logs and various specialized interfaces to
schema documentation and special function languages (plsh or plr).

With an upcoming windows release coming where the masses will be
watching, I think the former is more important at the moment.

A long time ago, in a galaxy far, far away, tgl@sss.pgh.pa.us (Tom Lane) wrote:

"Joshua D. Drake" <jd@commandprompt.com> writes:

My personal opinion is that contrib should be removed entirely.

That's not real workable for code that is tightly tied to the backend,
such as the various GIST index extensions presently in contrib. It's
just easier to maintain that code when it's in with the backend.

However the replication modules don't seem to have such a linkage,
so I have no objection to moving them out.

I'll point out one "fly in ointment" that has been noticed; on AIX,
there are compilation tools that are difficult to live without, namely
"mkldexport.sh", that lives pretty deep in the source tree.

Maybe the answer is to "replicate" ;-) that into the code base for
code that uses it. Alternatively, perhaps there needs to be a
"make-all-build-tools" target in the main makefile.

A challenge seems to be to have this play well with Linux and BSD
"package" systems; building packages that can automatically go to
sources (ala Ports or Source RPMs or auto-built .debs) for "contrib"
software is sure to be somewhat painful; doing the same for outside
code that also requires a PG source build is painful to think about.
--
"cbbrowne","@","ntlug.org"
http://www.ntlug.org/~cbbrowne/finances.html
Rules of the Evil Overlord #209. "I will not, under any circumstances,
marry a woman I know to be a faithless, conniving, back-stabbing witch
simply because I am absolutely desperate to perpetuate my family
line. Of course, we can still date." <http://www.eviloverlord.com/&gt;

On Wed, 21 Apr 2004, Bruce Momjian wrote:

I was thinking about CPAN. They have download stuff, but it installs
very easily. I wonder if we should allow gborg projects to interface to
our configure output in a way that makes it easier for them to be
installed.

No, because again that requires you to download a large tar ball just to
get the build environment?

The gborg is easy for development and releasing, but loses in the
easy-of-use category sometimes.

So, what we *should* be looking at it some sort of howto on how to setup
an autoconf environment ... the basics aren't too hard, its only when you
get into the more complicated stuff that only *large* projects tend to get
into that it gets particulary confusing ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

On Wed, 21 Apr 2004, Rod Taylor wrote:

We have the current issue of people not knowing that projects like
pgadmin exist or where to find the jdbc drivers.

Agreed ... but makign one big META package isn't going to fix that ... as
someone else suggested, put a README file in the contrib directory that
points ppl to projects.postgresql.org ...

These basic components (and others a large segment uses that are well
maintained) should go through a release cycle with the -core including
the platform test/report phase and be prominently listed in the
downloads area and documentation areas -- just as we do for PostgreSQL
proper.

*ack* ... now the beta cycle just quadrupled in length ... so we develop
for 4 months, and beta for a year while we make sure everyone else's
packages work with the -core?

Most DBAs that I know will not upgrade based on a .0 release on a
production system ... they will wait for at least a .1 release ... between
.0 and .1 is when projects like PgAdmin should be doing their testing to
make sure that they are good for the new major release ...

Goto http://postgresql.org, now track down the jdbc drivers or how to
use them. To a significant portion of our users this is more important
than CREATE FUNCTION is and in 7.5 jdbc documentation will be much more
difficult to find, but no less important than it used to be.

Now, out of all of the PostgreSQL users, what % are using JDBC? What %
are using ODBC? What percentage of those using JDBC are also using ODBC?
What % of those using PgAdmin are also using ODBC? For that matter, how
many ppl using JDBC only want to download the .jar file itself, and not
the source code? % of Binary-Only PgAdmin users? ODBC driver?

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 ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:

On Wed, 21 Apr 2004, Bruce Momjian wrote:

I was thinking about CPAN. They have download stuff, but it installs
very easily. I wonder if we should allow gborg projects to interface to
our configure output in a way that makes it easier for them to be
installed.

No, because again that requires you to download a large tar ball just to
get the build environment?

The gborg is easy for development and releasing, but loses in the
easy-of-use category sometimes.

So, what we *should* be looking at it some sort of howto on how to setup
an autoconf environment ... the basics aren't too hard, its only when you
get into the more complicated stuff that only *large* projects tend to get
into that it gets particulary confusing ...

There are only a few PostgreSQL developers who can do it, so what are
the odds that a single guy who maintains a plugin is going to be able to
do it. And you can say it is easy, but it just takes one complex
problem to hit you, and with PostgreSQL, and all the shared lib stuff
and dynamic loading, lots of it is complex.

Let's face it, unbundling is great for release efficiency, but terrible
for ease-of-use, and let me also tell you that that is where MySQL
shines and is perhaps taking new users from us. No secret there.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Wed, 21 Apr 2004, Joe Conway wrote:

Well, in the case of dblink, consider this:

- It is used by a fair number of people -- questions are answered on the
lists at least once a week with "see contrib/dblink".

A fair # of ppl are using erserver/bsd too ... should we add that in too?

- It is dependent on backend code to the extent that it cannot be built
outside of the contrib folder, unless some backend code is duplicated
in the external project. It also has no build system of its own.

k, so this one falls under 'too lazy to build a proper build system'

- dblink-type capability should someday make it into the backend, albeit
in the form of something compliant to the SQL/MED spec. This is
standard functionality in many of the RDBMSs that Postgres users
migrate from, and it is needed by enterprise users.

dblink isn't an integrated replication solution, it is a standalone one
... to date, I have not seen one replication solution that solves all the
issues, and unless someone comes up with the be all, end all replication
solution, none of them should be considered 'part of the backend' ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Joe Conway wrote:

Marc G. Fournier wrote:

Why is it the core developers responsibility to make sure that an
application stays in sync with the main tree? Personally, that is giving
life to software that could just as easily be unused by anyone, but kept
in the code base because "a commit was made to it less then 6 months ago"
...

Well, in the case of dblink, consider this:

- It is used by a fair number of people -- questions are answered on the
lists at least once a week with "see contrib/dblink".

- It is dependent on backend code to the extent that it cannot be built
outside of the contrib folder, unless some backend code is duplicated
in the external project. It also has no build system of its own.

Both very valid points and together they indicate a decision point ...

- dblink-type capability should someday make it into the backend, albeit
in the form of something compliant to the SQL/MED spec. This is
standard functionality in many of the RDBMSs that Postgres users
migrate from, and it is needed by enterprise users.

... which is right here.

Either dblink is vital, important and clean enough to move into the main
backend code, then let's do it. You claim it is vital and important, but
not clean? Then you know what to do.

[...]

In any case, I don't understand what the driver is to kill contrib. I
fully agree that it should be maintained (meaning that someone other
than core is interested enough to provide patches if non-trivial
maintenance is required to keep it compiling), and stuff that is not
used or suitably licensed should be removed. The contrib build system
ought to be maintained in working order in any case because it makes it
far easier to extend Postgres with your own functions.

The driver from my point of view is that some things have been sitting
in contrib for quite some time that are neither maintained, nor wanted
by anyone. Don't take it personal, I just chose dbmirror and dblink
because both fall to some degree into the same usage category as Slony,
and both are active projects (I hate shooting at sitting ducks). If we
can demonstrate that even projects as vital and complex as these two
have a turning point where it says "into the backend or out of contrib",
then things like "noupdate" or "userlock" will have a hard time to show
any reason to make an exception.

Anyway, just my 2cents.

Joe

Cool ... found 2 cents :-)

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

On Wed, 21 Apr 2004, Bruce Momjian wrote:

There are only a few PostgreSQL developers who can do it, so what are
the odds that a single guy who maintains a plugin is going to be able to
do it. And you can say it is easy, but it just takes one complex
problem to hit you, and with PostgreSQL, and all the shared lib stuff
and dynamic loading, lots of it is complex.

So, put together a developers kit ... you'd need, what, a half dozen files
to bootstrap a project with? configure.in, Makefile.in, a README file
with the basics on what needs to be modified in Makefile.in, the
src/template directory ...

If you are looking for a problem to solve, make it easier for developers
to setup a proper build environment, don't punish end-users to giving them
a bigger package to download

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

On Wed, 2004-04-21 at 22:43, Marc G. Fournier wrote:

On Wed, 21 Apr 2004, Rod Taylor wrote:

We have the current issue of people not knowing that projects like
pgadmin exist or where to find the jdbc drivers.

Agreed ... but makign one big META package isn't going to fix that ... as
someone else suggested, put a README file in the contrib directory that
points ppl to projects.postgresql.org ...

Considering the number of people asking about cross database queries,
anything in contrib will also be ignored.

It has to be on the front page of www.postgresql.org if we want people
to find it.

These basic components (and others a large segment uses that are well
maintained) should go through a release cycle with the -core including
the platform test/report phase and be prominently listed in the
downloads area and documentation areas -- just as we do for PostgreSQL
proper.

*ack* ... now the beta cycle just quadrupled in length ... so we develop
for 4 months, and beta for a year while we make sure everyone else's
packages work with the -core?

Come now. We all know of projects much much larger than PostgreSQL which
make more frequent releases.

This has nothing to do with timing, it has to do with organization. For
the most part the people working on the individual components of the
PostgreSQL Environment are different from those working on the core of
it. There is absolutely no reason we could not set a release date, stick
to it, and have all of the "important" projects ready for release at
that time.

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

I guess that is where we differ in opinion. pgadmin is not addon or an
enhancement, it is a part of the core project every bit as much as the
gnome-panel is a part of gnome. Sure, gnome-libs does all the heavy
lifting, but without the panel most users are lost.

On Wed, Apr 21, 2004 at 11:47:11PM -0300, Marc G. Fournier wrote:

On Wed, 21 Apr 2004, Joe Conway wrote:

- dblink-type capability should someday make it into the backend, albeit
in the form of something compliant to the SQL/MED spec. This is
standard functionality in many of the RDBMSs that Postgres users
migrate from, and it is needed by enterprise users.

dblink isn't an integrated replication solution, it is a standalone one
... to date, I have not seen one replication solution that solves all the
issues, and unless someone comes up with the be all, end all replication
solution, none of them should be considered 'part of the backend' ...

You are thinking of dbmirror, while Joe talks about dblink. It's
orthogonal functionality ...

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Cuando miro a alguien, m�s me atrae c�mo cambia que qui�n es" (J. Binoche)

Rod Taylor wrote:

I think most of the current contrib projects are more missing the
advantage version independence would have for the ease of "sitting" in
contrib and having the whole project management around them just done.
Yes, doing your own gborg project costs time. You have to maintain
pages, do your own release cycles with announcement, BETA phase,
tarballs, packaging and all the nine yards. Being in contrib avoids all
that in a very convenient way.

I think Gnome (and KDE) have the right idea. Several independent small
projects that once or twice a year get together and have a big release.

We could co-ordinate a set of projects (phppgadmin, pgadmin, slony,
jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL.

Maybe not this way, but I like the general idea of "grouping" multiple
smaller projects for release and overall project maintenance purposes.

CVS has the capability to combine multiple, separate modules into
symbolic names. With that, one can create exactly those "meta" checkouts
for nightly build systems, which could simply alarm a mailing list of
module admins if something goes wrong. Setting up a nightly build agains
CVS tip is nothing one would even think of for a simple loadable
extension, but if you just have to add the thing to a group and done,
Joe Conways concern is mostly answered.

Josh, is there anything that remotely sounds like this in the new system
you're setting up?

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Marc G. Fournier wrote:

On Wed, 21 Apr 2004, Bruce Momjian wrote:

There are only a few PostgreSQL developers who can do it, so what are
the odds that a single guy who maintains a plugin is going to be able to
do it. And you can say it is easy, but it just takes one complex
problem to hit you, and with PostgreSQL, and all the shared lib stuff
and dynamic loading, lots of it is complex.

So, put together a developers kit ... you'd need, what, a half dozen files
to bootstrap a project with? configure.in, Makefile.in, a README file
with the basics on what needs to be modified in Makefile.in, the
src/template directory ...

If you are looking for a problem to solve, make it easier for developers
to setup a proper build environment, don't punish end-users to giving them
a bigger package to download

Download (100% reliable to fix problem) vs. my time to build kit --- I
pick download.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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.

Hello,

I believe that one problem with the contrib is that in order to build
most of the contrib modules you need
the PostgreSQL source. That is silly. If I have PostgreSQL installed
with all headers, I should be able to
download a PostgreSQL project app (pgAdmin whatever) and just build it
against PostgreSQL.

Very few OSS projects are like that. If I want PHP I don't need Apache
source, I just need the Apache
development stuff (headers etc...).

If we were to break out contrib so it was on its own, let people figure
out their own build methods. You
don't "have" to use autoconf (although it is a good idea). You don't
NEED PostgreSQL source etc...

Sincerely,

Joshua D. Drake

Marc G. Fournier wrote:

On Wed, 21 Apr 2004, Rod Taylor wrote:

We have the current issue of people not knowing that projects like
pgadmin exist or where to find the jdbc drivers.

Agreed ... but makign one big META package isn't going to fix that ... as
someone else suggested, put a README file in the contrib directory that
points ppl to projects.postgresql.org ...

These basic components (and others a large segment uses that are well
maintained) should go through a release cycle with the -core including
the platform test/report phase and be prominently listed in the
downloads area and documentation areas -- just as we do for PostgreSQL
proper.

*ack* ... now the beta cycle just quadrupled in length ... so we develop
for 4 months, and beta for a year while we make sure everyone else's
packages work with the -core?

Most DBAs that I know will not upgrade based on a .0 release on a
production system ... they will wait for at least a .1 release ... between
.0 and .1 is when projects like PgAdmin should be doing their testing to
make sure that they are good for the new major release ...

Goto http://postgresql.org, now track down the jdbc drivers or how to
use them. To a significant portion of our users this is more important
than CREATE FUNCTION is and in 7.5 jdbc documentation will be much more
difficult to find, but no less important than it used to be.

Now, out of all of the PostgreSQL users, what % are using JDBC? What %
are using ODBC? What percentage of those using JDBC are also using ODBC?
What % of those using PgAdmin are also using ODBC? For that matter, how
many ppl using JDBC only want to download the .jar file itself, and not
the source code? % of Binary-Only PgAdmin users? ODBC driver?

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 ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

Marc G. Fournier wrote:

On Wed, 21 Apr 2004, Joe Conway wrote:

- It is dependent on backend code to the extent that it cannot be built
outside of the contrib folder, unless some backend code is duplicated
in the external project. It also has no build system of its own.

k, so this one falls under 'too lazy to build a proper build system'

No, I don't call that lazy, I call it smart. It makes use (reuse) of a
part of Postgres (the contrib build system) that is among its strengths.
Is it your goal to make it harder for people to write their own C
language functions? It makes no sense whatsoever to expect everyone who
wants to extend Postgres to develop their own build system. I'd call
that alot of duplicated effort -- effort better spent more productively.

dblink isn't an integrated replication solution, it is a standalone one
... to date, I have not seen one replication solution that solves all the
issues, and unless someone comes up with the be all, end all replication
solution, none of them should be considered 'part of the backend' ...

No one (including me) has ever claimed it is any kind of a replication
system. It is completely different functionality.

Joe

Bruce Momjian wrote:

I was thinking about CPAN. They have download stuff, but it installs
very easily. I wonder if we should allow gborg projects to interface to
our configure output in a way that makes it easier for them to be
installed.

Now that idea I like. The R project also has something similar that
allows a standard R command to download, compile, and install their
equivalent to contrib packages. They even have an automated system of
testing the contributed packages to ensure they work. If the package
doesn't meet certain standards, it is automatically dropped from the
link list on the download page. See:
http://cran.r-project.org/doc/manuals/R-exts.pdf
if you're interested. Very impressive, but also a huge amount of work to
set up.

The gborg is easy for development and releasing, but loses in the
easy-of-use category sometimes.

I agree.

Joe

Joe Conway wrote:

Bruce Momjian wrote:

I was thinking about CPAN. They have download stuff, but it installs
very easily. I wonder if we should allow gborg projects to interface to
our configure output in a way that makes it easier for them to be
installed.

Now that idea I like. The R project also has something similar that
allows a standard R command to download, compile, and install their
equivalent to contrib packages. They even have an automated system of
testing the contributed packages to ensure they work. If the package
doesn't meet certain standards, it is automatically dropped from the
link list on the download page. See:
http://cran.r-project.org/doc/manuals/R-exts.pdf
if you're interested. Very impressive, but also a huge amount of work to
set up.

The gborg is easy for development and releasing, but loses in the
easy-of-use category sometimes.

I agree.

I am thinking they could untar into a directory under pgsgl/ or have a
way to point to a 'configure'-run source tree and pull values from
there.

If you include pg_config.h, or use Makefile.global, you have almost
everything you need to compile your own, including flags, configure
checks, and the location of the installation directory.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

I am thinking they could untar into a directory under pgsgl/ or have a
way to point to a 'configure'-run source tree and pull values from
there.

If you include pg_config.h, or use Makefile.global, you have almost
everything you need to compile your own, including flags, configure
checks, and the location of the installation directory.

How hard would it be to have the individual cvs projects such that they
could be checked out all in one shot?

I'm thinking that if it was easy enough to maintain an up-to-date cvs
copy for all the individual projects, then it would be easy to grep the
entire mess when making backend changes. That way at least you could
determine the extent of the impact when making backend changes. And
since they are still individual projects, you don't need to get them all
if you're not interested.

Joe

On Thu, Apr 22, 2004 at 12:29:36AM -0400, Bruce Momjian wrote:

I am thinking they could untar into a directory under pgsgl/ or have a
way to point to a 'configure'-run source tree and pull values from
there.

If you include pg_config.h, or use Makefile.global, you have almost
everything you need to compile your own, including flags, configure
checks, and the location of the installation directory.

That would work only if they compiled the source themselves, as opposed
to using a binary package (which is very common). I'm not sure if
installing the postgresql-dev or postgresql-devel package would be
enough.

If not, maybe pg_config could provide all the necessary info ...

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Hi! I'm a .signature virus!
cp me into your .signature file to help me spread!

On Thu, Apr 22, 2004 at 12:41:28AM +0400, Oleg Bartunov wrote:

The problem with moving all contribs to gborg is that sometimes it's
required to change many modules, for example, because of changing
GiST interface. Tom saves a lot of working for contrib authors, when he
change code in core. I'm not sure, gborg would provide easy access for
such kind of things. tsearch2, particularly, is maintained in pgsql CVS.

Agree. The basic argue for removing something from contrib should be
that nobody maintain a module or that maintain it in the contrib is
difficult.

Other problem -- now maintainers of distribution PostgreSQL packages
(Debian/RH/...) make packages from the contrib tree. Are you sure they
will search something on sourceforge/gborg and make separate packeges
for each small script? How they will detect what is good for packaging?
The contrib tree is basic selection of interesting small thigs from
PostgreSQL world.

Karel

--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/

On Wed, 21 Apr 2004, Marc G. Fournier wrote:

On Wed, 21 Apr 2004, Rod Taylor wrote:

We have the current issue of people not knowing that projects like
pgadmin exist or where to find the jdbc drivers.

Now, out of all of the PostgreSQL users, what % are using JDBC? What %
are using ODBC? What percentage of those using JDBC are also using ODBC?
What % of those using PgAdmin are also using ODBC? For that matter, how
many ppl using JDBC only want to download the .jar file itself, and not
the source code? % of Binary-Only PgAdmin users? ODBC driver?

See the poll run on postgresql.org:
http://www.postgresql.org/survey.php?View=1&amp;SurveyID=24

It took several minutes to load for me so I'll include the results here:
Currently the results of our "What PostgreSQL API do you use the most?"
survey are:

Answer Responses Percentage
libpq 1752 13.116%
libpq++ 526 3.938%
libpqxx 176 1.318%
psqlODBC 2495 18.678%
JDBC 7607 56.947%
Npgsql 294 2.201%
ECPG 154 1.153%
pgtcl 354 2.650%
Total number of responses: 13358

You can certainly fault the choices (leaving perl, python, and php off the
list), but 7500 java users is something that can't be ignored.

The point is that any legitimate database will provide JDBC and ODBC
drivers. When new users can't immediately find them from the postgresql
home page they get frustrated and badmouth postgresql. Telling them to go
to gborg isn't really helpful. gborg is currently full of dead projects,
projects that have never had any code committed, and projects that are of
questionable utility. gborg is supposed to be the dumping ground for
these ala sourceforge, so it's not the dead projects I object to, so much
as the fact that serious and critical projects are grouped together with
them.

We need better packaging/promotion of secondary projects and the main
project can't be ignorant of this fact and cop out with "we just provide
the server."

Kris Jurka

Alvaro Herrera wrote:

On Thu, Apr 22, 2004 at 12:29:36AM -0400, Bruce Momjian wrote:

I am thinking they could untar into a directory under pgsgl/ or have a
way to point to a 'configure'-run source tree and pull values from
there.

If you include pg_config.h, or use Makefile.global, you have almost
everything you need to compile your own, including flags, configure
checks, and the location of the installation directory.

That would work only if they compiled the source themselves, as opposed
to using a binary package (which is very common). I'm not sure if
installing the postgresql-dev or postgresql-devel package would be
enough.

If not, maybe pg_config could provide all the necessary info ...

The pieces of the current build environment, used or possibly required
by any contrib module (including scripts like mkldexport.sh and such)
whold have to be installed under $datadir/devel or the like and made
location independent. That's all.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Taking into account that quite a few people have repeatedly stated that
the components in contrib are considered more supported/recommended than
similar solutions found on gborg or any other external site, I suggest
we move the projects dbmirror and dblink to gborg. The rserv contrib
module seems to me to be an early Perl prototype of erserver, nobody is
working on any more. I suggest we drop that entirely.

Comments/alternatives?

I love the idea, but (there is always a "but," isn't there?)

I agree with the notion that "contrib" be removed from the main
distribution. There is, however, a disconnect between supporting projects
and the main system.

Take a look at the www.postgresql.org web site. Most people visually
filter out the side bars. I've been looking over effectiveness of paid
advertisements in the various search engines, and the numbers are clear in
that the paid links at the top of the page get the hits while the side
hits get almost completely ignored. What I think this means is that people
looking for projects will simply filter out any reference to gborg.

What would be good, is to bring gborg a little closer to PostgreSQL by
putting a link in the main site menu. Rather than:

"Download - Mirrors - Lists - Users - Developers - Docs - Search"

We could have:

"Download - Docs - Lists - Search - Community - Contrib"

"Download" would be a unified version of the Download/Mirrors links on the
current site.

"Docs" Unchanged
"Lists" Unchanged
"Search" Unchanged
"Community" is a unified Users/Developers page.
"Contrib" is a link to GBorg.

Kris,

Thank you. I objected to having the jdbc code moved out of the base
product cvs tree for some of the reasons being discussed in this thread:
how are people going to find the jdbc driver, how will they get
documentation for it, etc.

I think the core problem is that some people view postgres as just the
database server proper. But most people (IMHO) view postgres (or any
database) as a set of things (core server, admin utils, drivers, etc).

I think the solution lies in improving www.postgresql.org. At the end
of the day it doesn't matter where source code lives, what matters is
can people find what they are expecting. Given we know what people are
looking for, that should be front and center on the web site and the ftp
sites.

--Barry

Kris Jurka wrote:

Jan,

Josh, is there anything that remotely sounds like this in the new system
you're setting up?

Not AFAIK. I'm really not a CVS person (as you may have gathered), but I'm
under the impression that GForge is a pretty "dumb" user of CVS.

As far as I'm concerned, what you've suggested is what we should be aiming
toward -- and is a reason to consider Subversion or ARCH if that's what it
takes. We *do* need CPAN-like plugabbility, but unfortunately, I am too
much of a collaboration neophyte to suggest how to construct one.

The reason to shrink contrib, from my perspective, is that we have too many
associated projects to include them *all* in contrib -- we'd be talking a
125MB download. Many of these packages (the GUIs, for example) are
redundant for any single user. And, if we continue to be successful as an
OSS project, we can expect the number of these packages to grow.

Which packages do and do not get included in /contrib has been a very
arbitrary process to date -- mostly having to do with convenience and how
involved the developer is on this list. I started thinking of this when
JDBC was moved out of contrib, over some protests, and started thinking,"why
should DBMirror be in contrib and JDBC not? Why is Tsearch in contrib and
guid not?"

Overally, contrib continues to form a sort of "stamp of approval" that add-ins
are "official" and part of PostgreSQL, while the stuff on GBorg is not.
This is unfair to the very good and userful projects which are on Gborg,
particularly considering the contrib items (like tsearch1 or postgres-r)
which are depreciated even by thier original owners!

We can't have *everything* in contrib -- the top 5 GUIs alone would triple the
size of our downloads. So we need to move in the opposite direction --
putting more stuff in pgFoundry, and letting packagers know that they should
package and include all "mature" projects on pgFoundry if they can. (our
earlier discussion proved that this list cannot realistically designate
"approved" vs. "unapproved" projects).

--
-Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus wrote:

We can't have *everything* in contrib -- the top 5 GUIs alone would triple the
size of our downloads. So we need to move in the opposite direction --
putting more stuff in pgFoundry, and letting packagers know that they should
package and include all "mature" projects on pgFoundry if they can. (our
earlier discussion proved that this list cannot realistically designate
"approved" vs. "unapproved" projects).

As I've said on other parts of this thread, my concern with moving
everything to gborg/pgFoundry is that it raises the bar in terms of
difficulty if we expect every individual project to develop their own
infrastructure. What we need to really make that work is to provide an
infrastructure similar to Perl's CPAN or the R project's CRAN. Imagine
how nice it would be if a relatively new Postgres user could do
something like this at a shell prompt:

pgFoundry install slony1
pgFoundry install plr
pgFoundry install tsearch2

That command would go to a standard URL (but maybe overridden by a
configuration option, say to look at a specific mirror, maybe even with
backup mirrors specified too) to grab a tarball, download it, untar it
to some specific location locally, then run make, make install, make
installcheck. The configuration information for the local Postgres
install would need to be handy somewhere, support for installcheck,
along with all headers (I'd think). I don't know all the details
required to make this work, but it would be very useful. Thoughts?

Joe

Taking into account that quite a few people have repeatedly stated that

the components in contrib are considered more supported/recommended than
similar solutions found on gborg or any other external site, I suggest
we move the projects dbmirror and dblink to gborg. The rserv contrib
module seems to me to be an early Perl prototype of erserver, nobody is
working on any more. I suggest we drop that entirely.

Comments/alternatives?

I love the idea, but (there is always a "but," isn't there?)

I agree with the notion that "contrib" be removed from the main
distribution. There is, however, a disconnect between supporting projects
and the main system.

Take a look at the www.postgresql.org web site. Most people visually
filter out the side bars. I've been looking over effectiveness of paid
advertisements in the various search engines, and the numbers are clear in
that the paid links at the top of the page get the hits while the side
hits get almost completely ignored. What I think this means is that people
looking for projects will simply filter out any reference to gborg.

What would be good, is to bring gborg a little closer to PostgreSQL by
putting a link in the main site menu. Rather than:

"Download - Mirrors - Lists - Users - Developers - Docs - Search"

We could have:

"Download - Docs - Lists - Search - Community - Contrib"

"Download" would be a unified version of the Download/Mirrors links on the
current site.

"Docs" Unchanged
"Lists" Unchanged
"Search" Unchanged
"Community" is a unified Users/Developers page.
"Contrib" is a link to GBorg.

I agree with the notion that "contrib" be removed
from the main distribution. There is, however, a
disconnect between supporting projects and the main system.

Take a look at the www.postgresql.org web site.
Most people visually filter out the side bars. I've
been looking over effectiveness of paid advertisements
in the various search engines, and the numbers are clear
in that the paid links at the top of the page get the hits
while the side hits get almost completely ignored. What I
think this means is that people looking for projects will
simply filter out any reference to gborg.

What would be good, is to bring gborg a little closer to
PostgreSQL by putting a link in the main site menu. Rather than:

What would be even better IMHO is to bring "gborg" a little close to
English or a word that makes sense to people visiting the PostgreSQL
site.

Is it "g-b-org" or "g-borg" or what? Is it a carry-over from the Great
Bridge days or some lame hacker reference to the Borg? I understand the
reference to Great Bridge, but do newbies?

Same goes for "pgfoundry". It might be obvious to the people already
using PostgreSQL, but those aren't the people that need help finding
something at the web site. What does a foundry have to do with computer
projects?

We're not associated with an iron-works or Bethlehem Steel, we're a
database project trying to attract and keep visitors. If users can't
find what they want at our site, they'll find it somewhere else or move
on to another product that helps them do what they want.

Instead of "gborg projects", why not just call it what it is, "supported
projects"?

Darren

On Wed, 21 Apr 2004, Bruce Momjian wrote:

Marc G. Fournier wrote:

On Wed, 21 Apr 2004, Bruce Momjian wrote:

There are only a few PostgreSQL developers who can do it, so what are
the odds that a single guy who maintains a plugin is going to be able to
do it. And you can say it is easy, but it just takes one complex
problem to hit you, and with PostgreSQL, and all the shared lib stuff
and dynamic loading, lots of it is complex.

So, put together a developers kit ... you'd need, what, a half dozen files
to bootstrap a project with? configure.in, Makefile.in, a README file
with the basics on what needs to be modified in Makefile.in, the
src/template directory ...

If you are looking for a problem to solve, make it easier for developers
to setup a proper build environment, don't punish end-users to giving them
a bigger package to download

Download (100% reliable to fix problem) vs. my time to build kit --- I
pick download.

Right, but you don't count ... you aren't an end-user

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

On Wed, 21 Apr 2004, Rod Taylor wrote:

I guess that is where we differ in opinion. pgadmin is not addon or an
enhancement, it is a part of the core project every bit as much as the
gnome-panel is a part of gnome. Sure, gnome-libs does all the heavy
lifting, but without the panel most users are lost.

No it isn't ... you don't need pgadmin, or jdbc, or libpgtcl, or ... to
run a PostgreSQL server ... you need the postgresql core, and, as things
are going, libpq and that is about it ... even psql is becoming less of a
requirement as the support utilities that have been using it move towards
C vs shell wrappers ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:

On Wed, 21 Apr 2004, Bruce Momjian wrote:

Marc G. Fournier wrote:

On Wed, 21 Apr 2004, Bruce Momjian wrote:

There are only a few PostgreSQL developers who can do it, so what are
the odds that a single guy who maintains a plugin is going to be able to
do it. And you can say it is easy, but it just takes one complex
problem to hit you, and with PostgreSQL, and all the shared lib stuff
and dynamic loading, lots of it is complex.

So, put together a developers kit ... you'd need, what, a half dozen files
to bootstrap a project with? configure.in, Makefile.in, a README file
with the basics on what needs to be modified in Makefile.in, the
src/template directory ...

If you are looking for a problem to solve, make it easier for developers
to setup a proper build environment, don't punish end-users to giving them
a bigger package to download

Download (100% reliable to fix problem) vs. my time to build kit --- I
pick download.

Right, but you don't count ... you aren't an end-user

True, but what the end users get is nothing because I don't have the
time. No configure, no build environment, very user-unfriendly.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Thu, 2004-04-22 at 20:09, Marc G. Fournier wrote:

On Wed, 21 Apr 2004, Rod Taylor wrote:

I guess that is where we differ in opinion. pgadmin is not addon or an
enhancement, it is a part of the core project every bit as much as the
gnome-panel is a part of gnome. Sure, gnome-libs does all the heavy
lifting, but without the panel most users are lost.

No it isn't ... you don't need pgadmin, or jdbc, or libpgtcl, or ... to
run a PostgreSQL server ... you need the postgresql core, and, as things
are going, libpq and that is about it ... even psql is becoming less of a
requirement as the support utilities that have been using it move towards
C vs shell wrappers ...

Thats actually my point. You don't need epiphany, gnome-panel, gcalc or
solitare to have a desktop you can use, but since a majority find those
items to be useful they have been included in the default desktop. Those
applications are not forced upon users who don't want them, nor are they
the only applications available.

The perception of PostgreSQL being difficult to use has very little to
do with the software itself. The decision has already been made that
MySQL is easy and PostgreSQL is difficult at the download page while the
user was trying to figure out if the software did what they require.

Simply put, nobody on this list is a typical PostgreSQL user. This is
shown by the simple fact that they care enough about the software to
have joined the list in the first place. A much more common PostgreSQL
user is someone who has been given a last minute task to complete and
wants to to get it over with as quickly as possible so they can go home.

Maybe I'm wrong. But I run into many more of the latter in my average
day than I do the former.

Bruce Momjian wrote:

Marc G. Fournier wrote:

Right, but you don't count ... you aren't an end-user

True, but what the end users get is nothing because I don't have the
time. No configure, no build environment, very user-unfriendly.

Exactly.

Joe

Joe Conway <mail@joeconway.com> writes:

As I've said on other parts of this thread, my concern with moving
everything to gborg/pgFoundry is that it raises the bar in terms of
difficulty if we expect every individual project to develop their own
infrastructure.

I think that's exactly right. It may be okay for the core project to
decide these little side projects are outside our responsibility ---
but what we had better take responsibility for is a framework within
which it's easy to maintain little side projects. The cost of that
infrastructure is too high to expect the little projects to handle it
individually.

What we need to really make that work is to provide an
infrastructure similar to Perl's CPAN or the R project's CRAN.

There's more than one issue. CPAN makes it easy for end users to find
and install little projects. We need that, but we also need to make it
easy for programmers to build and maintain those projects. There was
some speculation earlier in the thread about whether the existing
contrib framework would do as a basis --- I don't know if it can be made
to work, or if it's sufficient, but it might do. In any case we can't
just toss contrib modules over the side and expect that good things will
happen to them when they can't even be built outside the main tree.
The effort to fix that on a retail basis would alone guarantee that
they will be stillborn projects.

regards, tom lane

On Thursday 22 April 2004 13:55, Barry Lind wrote:

I think the solution lies in improving www.postgresql.org. At the end
of the day it doesn't matter where source code lives, what matters is
can people find what they are expecting. Given we know what people are
looking for, that should be front and center on the web site and the ftp
sites.

But of course that solution always stalls out when it comes down to picking
which projects get the special treatment of direct links from the main
website and which ones stay out of the spotlight. With JDBC you might make
the case that the comparable solutions are commercial code (though I suspect
some of the commercial distributors might argue that) but with things like
admin programs it gets even fuzzier as there are a whole slew of those
available as open source projects. If we include them all then we're back to
square one, but I've never seen anyone eager to make the decision of which
apps are "best" nor anyone terrible willing to let someone else make that
decision either.

BTW It's not that I am against the idea (if you haven't seen it, check out
http://dev.mysql.com/downloads/ for one implementation), it's just that it's
a radical departure from "the way things have always been done" and I'm not
confident that there would be enough support to make the changes.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Wed, 21 Apr 2004, Joe Conway wrote:

On Wed, 21 Apr 2004, Joe Conway wrote:

No, I don't call that lazy, I call it smart. It makes use (reuse) of a
part of Postgres (the contrib build system) that is among its strengths.
Is it your goal to make it harder for people to write their own C
language functions? It makes no sense whatsoever to expect everyone who
wants to extend Postgres to develop their own build system. I'd call
that alot of duplicated effort -- effort better spent more productively.

Then, like I mentined to Bruce, we should be looking at some sort of
template that those developers can work off of ... downloading an 11Meg
file to build a 2k module seems a wee bit excessive, no?

No one (including me) has ever claimed it is any kind of a replication
system. It is completely different functionality.

Sorry, my bad here ... I was mixing dblink with dbmirror ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Tom Lane wrote:

Joe Conway <mail@joeconway.com> writes:

As I've said on other parts of this thread, my concern with moving
everything to gborg/pgFoundry is that it raises the bar in terms of
difficulty if we expect every individual project to develop their own
infrastructure.

I think that's exactly right. It may be okay for the core project to
decide these little side projects are outside our responsibility ---
but what we had better take responsibility for is a framework within
which it's easy to maintain little side projects. The cost of that
infrastructure is too high to expect the little projects to handle it
individually.

What we need to really make that work is to provide an
infrastructure similar to Perl's CPAN or the R project's CRAN.

There's more than one issue. CPAN makes it easy for end users to find
and install little projects. We need that, but we also need to make it
easy for programmers to build and maintain those projects. There was
some speculation earlier in the thread about whether the existing
contrib framework would do as a basis --- I don't know if it can be made
to work, or if it's sufficient, but it might do. In any case we can't
just toss contrib modules over the side and expect that good things will
happen to them when they can't even be built outside the main tree.
The effort to fix that on a retail basis would alone guarantee that
they will be stillborn projects.

What if we create a build/ directory as part of install that
pg_config.h, Makefile.global, etc, anything a plugin would need, and
install it by default. Then, if we give folks an easy way to access
them from their own apps and Makefiles, it would solve most of the
problems.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Marc G. Fournier wrote:

On Wed, 21 Apr 2004, Joe Conway wrote:

On Wed, 21 Apr 2004, Joe Conway wrote:

No, I don't call that lazy, I call it smart. It makes use (reuse) of a
part of Postgres (the contrib build system) that is among its strengths.
Is it your goal to make it harder for people to write their own C
language functions? It makes no sense whatsoever to expect everyone who
wants to extend Postgres to develop their own build system. I'd call
that alot of duplicated effort -- effort better spent more productively.

Then, like I mentined to Bruce, we should be looking at some sort of
template that those developers can work off of ... downloading an 11Meg
file to build a 2k module seems a wee bit excessive, no?

OK, I think the number of files needed to build modules is small and I
think can be installed by default in a /build directory. I am thinking
that with a little script help, projects can build apps that look like
like Makefiles used in our core project.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Thu, 22 Apr 2004, Bruce Momjian wrote:

OK, I think the number of files needed to build modules is small and I
think can be installed by default in a /build directory. I am thinking
that with a little script help, projects can build apps that look like
like Makefiles used in our core project.

This is all I'm saying ... its like when we packaged up our first eRServer
... I didn't require our clients to go out and download PostgreSQL to
build it, I pulled in the few files from our build environment into the
package so that it could be built independently ...

Nice thing was, we were able to hit as many platforms as PostgreSQL did,
as building shared libraries and such was all there ready to go ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Bruce Momjian <pgman@candle.pha.pa.us> writes:

What if we create a build/ directory as part of install that
pg_config.h, Makefile.global, etc, anything a plugin would need, and
install it by default. Then, if we give folks an easy way to access
them from their own apps and Makefiles, it would solve most of the
problems.

No it wouldn't, because those files *do not work outside the build
tree*. There are built-in assumptions about where the Makefiles
themselves live relative to the include tree, where the invoking module
is relative to all that, etc. Certainly there are a couple of files we
need to install that we currently don't, but it's going to take some
actual work beyond that to fix the problem. See for example
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112244
and if you're interested try to fix it yourself; it didn't seem trivial
when I was poking at it.

The specific details aren't especially relevant to this thread, though.
What is relevant is that we agree to a commitment that we will make
it easy to build modules outside the current Postgres build environment,
and that we will have an ongoing commitment to make sure that that keeps
working.

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There's more than one issue. CPAN makes it easy for end users to find
and install little projects.

One thing I would like to see is a more direct link to the drivers
(e.g. DBD::Pg, JDBC) from the download page. I don't think they need to
live in contrib, but having them on the download page right next to
the latest PG server files would do wonders. All the maintainers of
external projects would have to do is make sure that the link points to
where they want it to.

For example. look at how MySQL handles the DBD::mysql client (which is
hosted at CPAN, not mysql).

http://dev.mysql.com/downloads/index.html

The download page above has the server links, a few others, and then:

"DBI -- for connecting to MySQL from Perl"

Clicking on "DBI" gives you a small, clean page that explains what DBI
is and gives links to DBI and DBD::mysql, both hosted on cpan.org.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200404230734

-----BEGIN PGP SIGNATURE-----

iD8DBQFAiQBDvJuQZxSWSsgRAqn5AJ4pEllgPCiTVfAcrK21r62RgD1tdACg4IHz
hAb4LBiqlIMbBF2bsXdZDDI=
=xPFb
-----END PGP SIGNATURE-----

Tom Lane wrote:

The specific details aren't especially relevant to this thread, though.
What is relevant is that we agree to a commitment that we will make
it easy to build modules outside the current Postgres build environment,
and that we will have an ongoing commitment to make sure that that keeps
working.

Agreed.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

The specific details aren't especially relevant to this thread, though.
What is relevant is that we agree to a commitment that we will make
it easy to build modules outside the current Postgres build environment,
and that we will have an ongoing commitment to make sure that that keeps
working.

Maybe you try to mimic apache "apxs" script behavior?
It allows to compile, install, configure new modules into apache.

pg_config is not convincing at the time:

shell> pg_config --includedir-server
/usr/local/pg750a/include/postgresql/server

shell> ls /usr/local/pg750a/include/postgresql/server
ls: /usr/local/pg750a/include/postgresql/server: No such file or directory

Too bad, server headers are not installed by default:-(

--
Fabien.

The specific details aren't especially relevant to this thread, though.
What is relevant is that we agree to a commitment that we will make
it easy to build modules outside the current Postgres build environment,
and that we will have an ongoing commitment to make sure that that keeps
working.

Maybe you should try to mimic apache "apxs" script behavior?
It allows to compile, install, configure new modules into apache.

pg_config is not convincing at the time:

shell> pg_config --includedir-server
/usr/local/pg750a/include/postgresql/server

shell> ls /usr/local/pg750a/include/postgresql/server
ls: /usr/local/pg750a/include/postgresql/server: No such file or directory

Too bad, server headers are not installed by default:-(

--
Fabien.

On Thu, 2004-04-22 at 23:05, Robert Treat wrote:

On Thursday 22 April 2004 13:55, Barry Lind wrote:

I think the solution lies in improving www.postgresql.org. At the end
of the day it doesn't matter where source code lives, what matters is
can people find what they are expecting. Given we know what people are
looking for, that should be front and center on the web site and the ftp
sites.

But of course that solution always stalls out when it comes down to picking
which projects get the special treatment of direct links from the main
website and which ones stay out of the spotlight. With JDBC you might make

Most end users don't care if they can choose between 20 administration
interfaces. They want to know which one works the best and just use
that.

Guidelines:

1. Must be fully functional with new release of PostgreSQL on day of
PostgreSQL release -- all features. (Admin programs should know how to
create and manage all objects).

2. Must function across a majority of platforms that PostgreSQL
supports.

3. Must be available for free. Something we could *and will* distribute
via CD or could be installed by default. Likewise, source code must be
available to ensure it does not become discontinued.

4. Must be high quality -- equivalent to that of PostgreSQL itself.

5. It should be something that a company selling PostgreSQL support
would be willing to take on.

6. Must have demonstrated the above prior to inclusion on the download
page (gone through a full cycle).

7. They must be willing to change the name to something generic. I.e.
PostgreSQL Administration Interface or PostgreSQL Java Connector.

In other-words, they need to be willing to be a part of the larger
PostgreSQL community. If someone thinks that the JDBC drivers are
broken, the JDBC folks should be open to debate on how to solve the
issues or otherwise argue that there are no problems. Same as how
PostgreSQL itself works.

I really don't see this as being any different than deciding which
buffer strategy or website style to use. One is better in some way so it
becomes a part of the system.

On Fri, 2004-04-23 at 11:02, Rod Taylor wrote:

On Thu, 2004-04-22 at 23:05, Robert Treat wrote:

On Thursday 22 April 2004 13:55, Barry Lind wrote:

I think the solution lies in improving www.postgresql.org. At the end
of the day it doesn't matter where source code lives, what matters is
can people find what they are expecting. Given we know what people are
looking for, that should be front and center on the web site and the ftp
sites.

But of course that solution always stalls out when it comes down to picking
which projects get the special treatment of direct links from the main
website and which ones stay out of the spotlight. With JDBC you might make

I really don't see this as being any different than deciding which
buffer strategy or website style to use. One is better in some way so it
becomes a part of the system.

The difference is that a "better" admin tool is very subjective where as
a buffer strategy is not... or maybe the difference is really that
everyone thinks they are qualified to pick a "better" admin tool, but
very few can really argue as to a better buffer strategy. While I think
your criteria is pretty close to what I would use, I still couldn't pick
which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql...
and even I did I bet some people would have a problem with my choices.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Thu, 2004-04-22 at 23:05, Robert Treat wrote:

The difference is that a "better" admin tool is very subjective where as
a buffer strategy is not... or maybe the difference is really that
everyone thinks they are qualified to pick a "better" admin tool, but
very few can really argue as to a better buffer strategy. While I think
your criteria is pretty close to what I would use, I still couldn't pick
which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql...
and even I did I bet some people would have a problem with my choices.

I think the issue is that is gborg/pgfoundy should not just be a
sourceforge like tool for postgresql related applications. If they are
then someone looking for a gui admin tool for exmaple has to try them all
out only to find that 75% of them are half started projects that haven't
been maintained in two years, at least that is my typical experience with
sourceforge, and I know that is an issue with gborg right now.

Perhaps we could have some type of system whereby we can rank apps that as
tier1 supported or some such thing. The end user can still make his
subjective choice as to which is best, since nothing prevents us from
having 4 different tier1 supported gui admin apps, but the enduser would
be able to weed out most of the apps that aren't even close.

The difference is that a "better" admin tool is very subjective where as
a buffer strategy is not... or maybe the difference is really that
everyone thinks they are qualified to pick a "better" admin tool, but
very few can really argue as to a better buffer strategy. While I think
your criteria is pretty close to what I would use, I still couldn't pick
which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql...
and even I did I bet some people would have a problem with my choices.

If you have a hard time picking between those projects, imagine the
difficulties someone who has never used PostgreSQL has just tracking
down the options available to them.

We would not be removing any choices for the user. We're simply
supplying a list of suggested tools that they may have interest in.

Getting the user to download PostgreSQL and give it a shot without
becoming frustrated because the "basics" were not available (in an
obvious location) is the first step.

Step 2 is to inform the user that there are more alternatives available.
I see pgFoundary doing a good job of #2 -- but it is not going to help
with #1 (too much choice is as bad as none at all to a beginner).

Rod Taylor <pg@rbt.ca> writes:

The difference is that a "better" admin tool is very subjective where as
a buffer strategy is not... or maybe the difference is really that
everyone thinks they are qualified to pick a "better" admin tool, but
very few can really argue as to a better buffer strategy. While I think
your criteria is pretty close to what I would use, I still couldn't pick
which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql...
and even I did I bet some people would have a problem with my choices.

If you have a hard time picking between those projects, imagine the
difficulties someone who has never used PostgreSQL has just tracking
down the options available to them.

Exactly. MySQL makes no bones about choosing "blessed" projects. I
don't think that MySQL AB's MySQL Control Center is the best MySQL
GUI, but it's better than the "default" PostgreSQL choice. MySQL
shoves a workable solution under the end user's nose. PostgreSQL
gives the potential user a wide array of choices, none of which are
particularly easy to find. How many GUI tools are listed on GBorg?
How many potential users even know to look at GBorg at all?

One thing is certain most users aren't going to find psql (probably
compiled without readline support) comparable with MySQL Control
Center. Not to mention the fact that not having a set of "blessed"
tools means that we end up with competing tools. PostgreSQL has
several replication toolsets, piles of admin tools, and several
competing language bindings for some of the most popular development
languages.

How many Python bindings does PostgreSQL need?

PostgreSQL has some amazing supporting tools, but they are all hidden
in an unlighted basement in a locked filing cabinet next to a sign
that reads "Beware of the Leopard."

We would not be removing any choices for the user. We're simply
supplying a list of suggested tools that they may have interest in.

Exactly. Yes, choosing tools requires some politics, and it will
inevitably make some users and developers upset because their projects
will get passed over for more popular ones. However, this will
certainly help new users that are looking at PostgreSQL for the first
time. They will be able to see, right off, what *sort* of tools are
available for use with PostgreSQL. Later on as these people become
part of the PostgreSQL community they might even find out about
alternative tools that they like better.

Getting the user to download PostgreSQL and give it a shot without
becoming frustrated because the "basics" were not available (in an
obvious location) is the first step.

PostgreSQL stacks up well as a database. In fact, it rocks. But
comparing plain Jane PostgreSQL against other databases and their
assorted suite of tools is not going to work in PostgreSQL's favor.
Fortunately PostgreSQL has comparable supporting tools as well.
Unfortunately no one knows about these tools except for those of us on
the PostgreSQL lists.

Step 2 is to inform the user that there are more alternatives available.
I see pgFoundary doing a good job of #2 -- but it is not going to help
with #1 (too much choice is as bad as none at all to a beginner).

Precisely. The trick is to promote PostgreSQL and a core set of
tools. These tools don't have to be part of PostgreSQL's CVS (or even
be available for download) from the postgresql.com site, but they
should receive "top" billing. When the end user looks for a GUI,
there should be a single solitary GUI that should be the "default"
choice. When the end user asks about replication they should be
guided to a single solution. In cases where it is difficult to decide
what the default case might be--like in the case of replication where
the tools you will want to use depends on what you are trying to
accomplish--simply point users at the most common scenario and then
document that they might need to use other tools to solve different
problems.

Jason

On Fri, Apr 23, 2004 at 01:05:40AM -0300, Marc G. Fournier wrote:

This is all I'm saying ... its like when we packaged up our first eRServer
... I didn't require our clients to go out and download PostgreSQL to
build it, I pulled in the few files from our build environment into the
package so that it could be built independently ...

I am the last person in the world to cast aspersions on anyone's
packaging, but I'm not sure holding erserver up as a paradigm case of
easy compilation outside the main build tree is going to make your
argument easier here.

A

--
Andrew Sullivan | ajs@crankycanuck.ca

On Thu, 22 Apr 2004 pgsql@mohawksoft.com wrote:

"Download - Mirrors - Lists - Users - Developers - Docs - Search"

We could have:

"Download - Docs - Lists - Search - Community - Contrib"

"Download" would be a unified version of the Download/Mirrors links on the
current site.

I don't agree with this, since mirrors are web mirrors ... but I do like
the 'Contrib' pointing to gborg/projects ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

"Marc G. Fournier" <scrappy@postgresql.org> writes:

I don't agree with this, since mirrors are web mirrors ... but I do like
the 'Contrib' pointing to gborg/projects ...

Yeah, I like the contrib link idea too. Much of the recent discussion
comes down to gborg not being visible enough.

However ... how do we handle things once pgfoundry is online too?

(I suppose two links labeled "Old Contrib" and "New Contrib" might serve
as a forcing function to get projects to migrate over ;-))

regards, tom lane

"Marc G. Fournier" <scrappy@postgresql.org> writes:

I don't agree with this, since mirrors are web mirrors ... but I do like
the 'Contrib' pointing to gborg/projects ...

Yeah, I like the contrib link idea too. Much of the recent discussion
comes down to gborg not being visible enough.

However ... how do we handle things once pgfoundry is online too?

(I suppose two links labeled "Old Contrib" and "New Contrib" might serve
as a forcing function to get projects to migrate over ;-))

If there is going to be a change, i.e. Great Bridge is going away, and
being replaced with pgfoundary, I would suggest that you notify everyone
of a date and make it happen. Conversely, on pgfoundary, make a link to
gborg calling it "old projects" or something like that.

Take a look at this mock-up:
http://www.mohawksoft.com/PostgreSQL.html

(I am not a good web developer, I just moved a few things around, but I
hope you get what I'm trying to say)

A good web design makes no assumption that the visitor knows anything
about you. Like "mirrors" or "download," whis would tend to confuse first
time visitors. A single "Download" link should take the user to a page
that explains http/ftp and provides the various source links. Similarly, a
"Contrib" should take the user to a single place, gborg now, pgfoundary
later. Pgfoundary can then direct them to gborg if the project they are
searching for is not there.

The main problem with hard to use or "cluttered" web sites is that techies
like ourselves tend to put too much up front. Simple is better. Open up a
browser window on www.PostgreSQL.org. Don't resize window, assume 1024x768
screen, and maybe 3/4 or 2/3 of the screen is taken by the browser Window.
What do you see?

You have to scroll to see gborg and the odbc driver and replication, two
very important projects. All the visual clues needed to find things need
to be seen in that first window or people will not see them. In my screen,
the bottom says "User Survey" and "Websites" There are no visual clues
that something like gborg would show up if I scrolled down.

Yes, you can "The user should just scroll down," but they don't. Period.
It is like the first paragraph in a news article, if you don't grap the
user there, you won't.

Lastly there is grouping and relevence. Why is gborg lower on the page
than "User Survey?" Isn't gborg more important to the users than the user
survey? Why are there two links to gborg, one under websites and the
other under gborg, abd both are under the scroll line. Why is there a link
to "mailing list archives" under websites and as a top level link on the
menu?

All this critisizm aside, I generally like the look of the website, even
thought the elephant banner doesn't line up with the PostgreSQL banner :-)
It is just that the content and the presentation can be streamlined,
taking out redundant links and info, removing logically similar choices
i.e. "Download" and "Mirrors," adding "Contrib," and organizing more
important stuff at the top and down the middle, with less relvent stuff to
the right.

On Wed, Apr 21, 2004 at 10:25:29PM -0400, Christopher Browne wrote:

I'll point out one "fly in ointment" that has been noticed; on AIX,
there are compilation tools that are difficult to live without, namely
"mkldexport.sh", that lives pretty deep in the source tree.

That's just a problem to do with autoconf. All we gots to do is find
an autoconf genius. I don't think it entails that we need a complete
built source tree for everything.

A

--
Andrew Sullivan | ajs@crankycanuck.ca