Thread: contrib vs. gborg/pgfoundry for replication solutions

contrib vs. gborg/pgfoundry for replication solutions

From
Jan Wieck
Date:
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?


Jan

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



Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Joshua D. Drake"
Date:
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:

> 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?
> 
> 
> Jan
> 


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Matthew T. O'Connor"
Date:
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



Re: contrib vs. gborg/pgfoundry for replication solutions

From
Tom Lane
Date:
"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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Dave Page"
Date:

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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Joshua D. Drake"
Date:
> 
> 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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Jan Wieck
Date:
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 #



Re: contrib vs. gborg/pgfoundry for replication solutions

From
Tom Lane
Date:
"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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"scott.marlowe"
Date:
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:

> 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:
> 
> > 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?
> > 
> > 
> > Jan
> > 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
> 



Re: contrib vs. gborg/pgfoundry for replication solutions

From
Oleg Bartunov
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Joshua D. Drake"
Date:
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:

> 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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Magnus Hagander"
Date:
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

> -----Original Message-----
> From: scott.marlowe [mailto:scott.marlowe@ihs.com]
> Sent: Wednesday, April 21, 2004 10:03 PM
> To: Joshua D. Drake
> Cc: Jan Wieck; PostgreSQL-development
> Subject: Re: [HACKERS] contrib vs. gborg/pgfoundry for
> replication solutions
>
>
> 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:
>
> > 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:
> >
> > > 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?
> > >
> > >
> > > Jan
> > >
> >
> > ---------------------------(end of
> > broadcast)---------------------------
> > TIP 8: explain analyze is your friend
> >
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faqs/FAQ.html
>


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Josh Berkus
Date:
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 BerkusAglio Database SolutionsSan Francisco



Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Joshua D. Drake"
Date:
> 
> 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




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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Jan Wieck
Date:
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 #



Re: contrib vs. gborg/pgfoundry for replication solutions

From
Rod Taylor
Date:
> 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.



Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Joe Conway
Date:
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
backendcode 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/MEDspec. This is  standard functionality in many of the RDBMSs that Postgres users  migrate from, and it is needed
byenterprise users.
 

- The maintenance burden on core developers is pretty minimal. Recent  examples of where it was touched due to other
changesin 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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Rod Taylor
Date:
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.



Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Jan Wieck
Date:
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 #



Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Joe Conway
Date:
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



Re: contrib vs. gborg/pgfoundry for replication solutions

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Joe Conway
Date:
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



Re: contrib vs. gborg/pgfoundry for replication solutions

From
Alvaro Herrera
Date:
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!


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Alvaro Herrera
Date:
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)


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Jan Wieck
Date:
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 #



Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Joshua D. Drake"
Date:
Hello,<br /><br /> I believe that one problem with the contrib is that in order to build most of the contrib modules
youneed<br /> the PostgreSQL source. That is silly. If I have PostgreSQL installed with all headers, I should be able
to<br/> download a PostgreSQL project app (pgAdmin whatever) and just build it against PostgreSQL.<br /><br /> Very few
OSSprojects are like that. If I want PHP I don't need Apache source, I just need the Apache<br /> development stuff
(headersetc...).<br /><br /> If we were to break out contrib so it was on its own, let people figure out their own
buildmethods. You<br /> don't "have" to use autoconf (although it is a good idea). You don't NEED PostgreSQL source
etc...<br/><br /> Sincerely,<br /><br /> Joshua D. Drake<br /><br /><br /> Marc G. Fournier wrote:<br /><blockquote
cite="mid20040421232718.C32445@ganymede.hub.org"type="cite"><pre wrap="">On Wed, 21 Apr 2004, Rod Taylor wrote:
 
 </pre><blockquote type="cite"><pre wrap="">We have the current issue of people not knowing that projects like
pgadmin exist or where to find the jdbc drivers.   </pre></blockquote><pre wrap="">
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 ...
 </pre><blockquote type="cite"><pre wrap="">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.   </pre></blockquote><pre wrap="">
*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 ...
 </pre><blockquote type="cite"><pre wrap="">Goto <a class="moz-txt-link-freetext"
href="http://postgresql.org">http://postgresql.org</a>,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.   </pre></blockquote><pre wrap="">
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 (<a class="moz-txt-link-freetext"
href="http://www.hub.org">http://www.hub.org</a>)
Email: <a class="moz-txt-link-abbreviated" href="mailto:scrappy@hub.org">scrappy@hub.org</a>           Yahoo!: yscrappy
            ICQ: 7615664 </pre></blockquote><br /><br /><pre class="moz-signature" cols="72">-- 
 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - <a class="moz-txt-link-abbreviated" href="mailto:jd@commandprompt.com">jd@commandprompt.com</a> - <a
class="moz-txt-link-freetext"href="http://www.commandprompt.com">http://www.commandprompt.com</a>
 
PostgreSQL Replicator -- production quality replication for PostgreSQL</pre>

Re: contrib vs. gborg/pgfoundry for replication solutions

From
Joe Conway
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Karel Zak
Date:
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 bethat nobody  maintain a module  or that maintain
it in the  contrib isdifficult.
 
Other problem  -- now  maintainers of distribution  PostgreSQL packages(Debian/RH/...) make packages from the  contrib
tree.Are you sure theywill search  something on sourceforge/gborg and  make separate packegesfor each small script? How
theywill detect what is good for packaging?The contrib  tree is  basic selection of  interesting small  thigs
fromPostgreSQLworld.
 
   Karel

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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Rod Taylor
Date:
> 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.




Re: contrib vs. gborg/pgfoundry for replication solutions

From
Rod Taylor
Date:
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.




Re: contrib vs. gborg/pgfoundry for replication solutions

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Kris Jurka
Date:

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




Re: contrib vs. gborg/pgfoundry for replication solutions

From
Jan Wieck
Date:
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 #





Re: contrib vs. gborg/pgfoundry for replication solutions

From
Josh Berkus
Date:
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 BerkusAglio Database SolutionsSan Francisco



Re: contrib vs. gborg/pgfoundry for replication solutions

From
Barry Lind
Date:
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,
howwill 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:
> 
> 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&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
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match



Re: contrib vs. gborg/pgfoundry for replication solutions

From
pgsql@mohawksoft.com
Date:
> 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.


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Darren King"
Date:
> 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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Joe Conway
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
pgsql@mohawksoft.com
Date:
> 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.




Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Rod Taylor
Date:
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.




Re: contrib vs. gborg/pgfoundry for replication solutions

From
Joe Conway
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Tom Lane
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Robert Treat
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Tom Lane
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Greg Sabino Mullane"
Date:
-----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-----




Re: contrib vs. gborg/pgfoundry for replication solutions

From
Jan Wieck
Date:
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 #



Re: contrib vs. gborg/pgfoundry for replication solutions

From
Fabien COELHO
Date:
> > 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.


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Rod Taylor
Date:
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.



Re: contrib vs. gborg/pgfoundry for replication solutions

From
Robert Treat
Date:
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



Re: contrib vs. gborg/pgfoundry for replication solutions

From
Rod Taylor
Date:
> 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).



Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Matthew T. O'Connor"
Date:
>> 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.



Re: contrib vs. gborg/pgfoundry for replication solutions

From
jearl@bullysports.com
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Andrew Sullivan
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
"Marc G. Fournier"
Date:
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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Tom Lane
Date:
"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


Re: contrib vs. gborg/pgfoundry for replication solutions

From
pgsql@mohawksoft.com
Date:
> "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.




Re: contrib vs. gborg/pgfoundry for replication solutions

From
Christopher Browne
Date:
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/>


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Fabien COELHO
Date:
> > 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.


Re: contrib vs. gborg/pgfoundry for replication solutions

From
Andrew Sullivan
Date:
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