Thread: contrib vs. gborg/pgfoundry for replication solutions
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 #
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 >
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
Joshua D. Drake wrote: > Hello, > > My personal opinion is that contrib should be removed entirely. Just > have a contrib.txt that says all contrib modules are at pgfoundry or > whatever. I'm not so sure that's a good idea. I think contrib is a good repository for code that is tightly tied to the backend, or provides extentions to the backen, or is something that will eventually be integrated into the backend, but just isn't ready for prime time yet (pg_autovacuum for example). The value of contrib is exposure. I firmly believe that pg_autovacuum would not have gotten as much testing from gborg as it has from contrib. Perhaps the definition of what should be in contrib should be tightened down, and anything that doesn't meet that definition should be removed, but I think contrib is a good concept. Matthew
"Joshua D. Drake" <jd@commandprompt.com> writes:
> My personal opinion is that contrib should be removed entirely.
That's not real workable for code that is tightly tied to the backend,
such as the various GIST index extensions presently in contrib. It's
just easier to maintain that code when it's in with the backend.
However the replication modules don't seem to have such a linkage,
so I have no objection to moving them out.
regards, tom lane
> -----Original Message----- > From: Joshua D. Drake [mailto:jd@commandprompt.com] > Sent: 21 April 2004 19:16 > To: Jan Wieck > Cc: PostgreSQL-development > Subject: Re: [HACKERS] contrib vs. gborg/pgfoundry for > replication solutions > > Hello, > > My personal opinion is that contrib should be removed > entirely. Just have a contrib.txt that says all contrib > modules are at pgfoundry or whatever. Couldn't agree more. Regards, Dave.
On Wed, 21 Apr 2004, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > My personal opinion is that contrib should be removed entirely. > > That's not real workable for code that is tightly tied to the backend, > such as the various GIST index extensions presently in contrib. It's > just easier to maintain that code when it's in with the backend. > > However the replication modules don't seem to have such a linkage, > so I have no objection to moving them out. Agreed ... but I also think that something like pg_autovacuum should be moved to gborg ... there seems to be alot of activity on fixing bugs in it that most ppl won't see until they upgrade to the next release, even though those fixes would be pertinent/useful to their current implementation ... begin able to download/install pg_autovacuum 1.1 would definitely be a good thing, when it was considered stable enoguh for a release ... tsearch, I believe, is maintained somewhere else already, no? same with tsearch2? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> > tsearch, I believe, is maintained somewhere else already, no? same with > tsearch2? Yes that is correct but I think they commit back to contrib before they release. Realistically, although I did not used to agree, I believe that the only that that should come with PostgreSQL is PostgreSQL and required items for PostgreSQL. IMHO: PostgreSQL should include: PostgreSQL Psql All development headers C/C++ Libs Everything else should be on SourceForge or Gforge or whatever. The possible exception would be the pl stuff. Sincerely, Joshua D. Drake > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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 #
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Wed, 21 Apr 2004, Tom Lane wrote:
>> "Joshua D. Drake" <jd@commandprompt.com> writes:
>>> My personal opinion is that contrib should be removed entirely.
>>
>> That's not real workable for code that is tightly tied to the backend,
>> such as the various GIST index extensions presently in contrib. It's
>> just easier to maintain that code when it's in with the backend.
> tsearch, I believe, is maintained somewhere else already, no? same with
> tsearch2?
No, those guys are exactly the sort of backend-dependent code I'm
thinking of. Teodor just recently made a GIST API change that affected
both the core backend and tsearch (as well as the other GIST modules in
contrib). With separate distribution trees that would've been a lot
more painful to do.
I think the long-term plan for tsearch2, at least, should be full
integration rather than separation ...
regards, tom lane
I almost agree, but I think things that are being actively developed to eventually move into the backend, like autovacuum or slony-I should be in contrib. Things that aren't destined for backend integration should be removed though, like pgbench or dblink or whatnot. On Wed, 21 Apr 2004, Joshua D. Drake wrote: > 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 >
The problem with moving all contribs to gborg is that sometimes it's required to change many modules, for example, because of changing GiST interface. Tom saves a lot of working for contrib authors, when he change code in core. I'm not sure, gborg would provide easy access for such kind of things. tsearch2, particularly, is maintained in pgsql CVS. Oleg On Wed, 21 Apr 2004, Joshua D. Drake wrote: > > > > > tsearch, I believe, is maintained somewhere else already, no? same with > > tsearch2? > > Yes that is correct but I think they commit back to contrib before they > release. > > Realistically, although I did not used to agree, I believe that the only > that that should come with PostgreSQL is PostgreSQL and required items > for PostgreSQL. > > IMHO: PostgreSQL should include: > > PostgreSQL > Psql > All development headers > C/C++ Libs > > > Everything else should be on SourceForge or Gforge or whatever. The > possible exception would be the pl stuff. > > Sincerely, > > Joshua D. Drake > > > > > > > > > ---- > > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Hello, Well perhaps we can have exceptions. TSearch would be a good exception as it really should be integrated into PostgreSQL anyway. There are very few of these that I think would be an issue. Sincerely, Joshua D. Drake Oleg Bartunov wrote: > 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
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 >
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
On Wed, 21 Apr 2004, Tom Lane wrote: > No, those guys are exactly the sort of backend-dependent code I'm > thinking of. Teodor just recently made a GIST API change that affected > both the core backend and tsearch (as well as the other GIST modules in > contrib). With separate distribution trees that would've been a lot > more painful to do. > > I think the long-term plan for tsearch2, at least, should be full > integration rather than separation ... But there should be some sort of path to full integration ... isdb_ibbn(sp?) has been there forever, and I canj't see it ever being integrated ... Personally, the neat thing about PostgreSQL is that we are extendible(sp?) quite easily, and stuff like tsearch, earthdistance, postgis, etc all show that very nicely ... why add for the sake of adding? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Wed, 21 Apr 2004, scott.marlowe wrote: > I almost agree, but I think things that are being actively developed to > eventually move into the backend, like autovacuum or slony-I should be in > contrib. Things that aren't destined for backend integration should be > removed though, like pgbench or dblink or whatnot. Slony-I involves no backend integration that I've seen in its docs ... Jan? Did I miss something? As far as stuff like autovacuum, though ... its something that could definitely benefit from a seperate release cycle from the main code ... Has anyone looked at developing an Installer/packaging system so that as far as the code is concerned, thing are seperate projects, but for the end user ... The thing is, for how many ppl are seperate packages difficult? I know for me, under FreeBSD, I cd to a /usr/ports/databases/pg_autovacuum and type 'make install' and its done ... I thought that stuff like Redhat had the full screen installer that lists things? My point is that all of this stuff shouldn't be in the core CVS ... its a packaging issue, not a cvs one ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Wed, 21 Apr 2004, Jan Wieck wrote: > Joe Conway wrote: > > > Jan Wieck wrote: > >> Taking into account that quite a few people have repeatedly stated that > >> the components in contrib are considered more supported/recommended than > >> similar solutions found on gborg or any other external site, I suggest > >> we move the projects dbmirror and dblink to gborg. The rserv contrib > >> module seems to me to be an early Perl prototype of erserver, nobody is > >> working on any more. I suggest we drop that entirely. > >> > >> Comments/alternatives? > > > > dblink gets regularly updated as and when things change which affect it > > in the backend. It is more tightly bond to the backend than a client > > application, which the replication solutions you mention are. It is not > > a replication solution anyway, so I'm not sure why you would categorize > > in that way. > > None of the replication solutions I see are client applications only. > Substantial parts of erserver and Slony for example are loadable modules > and stored procedures, tightly bond to the backend by using data and > functionality not available via the SPI. So the same problems apply > here, which then would be a reason to add them to contrib as well? Why is it the core developers responsibility to make sure that an application stays in sync with the main tree? Personally, that is giving life to software that could just as easily be unused by anyone, but kept in the code base because "a commit was made to it less then 6 months ago" ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Thu, 22 Apr 2004, Magnus Hagander wrote: > > IMHO it's not all that important where the source is developed (core > cvs, gborg etc) - whichever suits the development/release model best > shuold be used (meaning inside core only if it should be released on the > very same schedule as the main backend only). > > What is more important is the exposure of the released versions. I think > it should be possible (and fairly easy) for projects developed outside > the core to get included in the "official download page", meaning go on > the ftp site and mirrors. Today it seems ODBC and pgadmin3 go there, but > pretty much nothing else (not even JDBC?). Perhaps a good structure > there would allow more proejcts to get that kind of exposure, and be > easier to find. I see no reaosn why projects can't be mirrored into the main ftp server, and brought through the mirrors ... > I quite often get people who claim "there is no this or that" for pgsql > when it's on gborg - simply becauase they didn't find it on the ftp > site. If you go looking, you'll find it on gborg, but if you don't know > where to look it can be hard. Especially for newcomers. ftp://gborg.postgresql.org/pub - ls everything is listed there ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> > The thing is, for how many ppl are seperate packages difficult? I know > for me, under FreeBSD, I cd to a /usr/ports/databases/pg_autovacuum and > type 'make install' and its done ... I thought that stuff like Redhat had > the full screen installer that lists things? Well, if setup correctly for redhat, debian or even SuSE you would type: apt-get install pg_autovacuum or with redhat you might also do yum install pg_autovacuum But that is packaging and that is up to the developers of the particular project. Joshua D. Drake > > 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
Marc G. Fournier wrote: > On Wed, 21 Apr 2004, scott.marlowe wrote: > >> I almost agree, but I think things that are being actively developed to >> eventually move into the backend, like autovacuum or slony-I should be in >> contrib. Things that aren't destined for backend integration should be >> removed though, like pgbench or dblink or whatnot. > > Slony-I involves no backend integration that I've seen in its docs ... > Jan? Did I miss something? Slony-I is intended to be PG version independent as much as possible. It would rather hurt to move it into contrib. Sure are there backend dependencies to #ifdef/#else, but for Slony-I this is considered a strength, not a problem. How else would it be possible to use Slony-I to do a PostgreSQL major version upgrade of multi-GB databases with only a few seconds interruption? > > As far as stuff like autovacuum, though ... its something that could > definitely benefit from a seperate release cycle from the main code ... > > Has anyone looked at developing an Installer/packaging system so that as > far as the code is concerned, thing are seperate projects, but for the end > user ... > > The thing is, for how many ppl are seperate packages difficult? I know > for me, under FreeBSD, I cd to a /usr/ports/databases/pg_autovacuum and > type 'make install' and its done ... I thought that stuff like Redhat had > the full screen installer that lists things? I think most of the current contrib projects are more missing the advantage version independence would have for the ease of "sitting" in contrib and having the whole project management around them just done. Yes, doing your own gborg project costs time. You have to maintain pages, do your own release cycles with announcement, BETA phase, tarballs, packaging and all the nine yards. Being in contrib avoids all that in a very convenient way. > > My point is that all of this stuff shouldn't be in the core CVS ... its a > packaging issue, not a cvs one ... Exactly. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
> I think most of the current contrib projects are more missing the > advantage version independence would have for the ease of "sitting" in > contrib and having the whole project management around them just done. > Yes, doing your own gborg project costs time. You have to maintain > pages, do your own release cycles with announcement, BETA phase, > tarballs, packaging and all the nine yards. Being in contrib avoids all > that in a very convenient way. I think Gnome (and KDE) have the right idea. Several independent small projects that once or twice a year get together and have a big release. We could co-ordinate a set of projects (phppgadmin, pgadmin, slony, jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL. We then setup several 'meta' packages. For example, PostgreSQL-lite might be just the core. PostgreSQL-Advanced might include jdbc, pgadmin, slony, tsearch, postgis and everything in postgresql-lite. Those who know what they want would be free to install the individual packages just like with Gnome you can install epiphany and it'll pull in everything needed for it without any extras. I suppose one trick is allowing things like Postgis to be compiled without requiring the source code to be around -- although I suppose we could suggest a postgresql-headers package which Mozilla did that for a while.
On Wed, 21 Apr 2004, Rod Taylor wrote: > > I think most of the current contrib projects are more missing the > > advantage version independence would have for the ease of "sitting" in > > contrib and having the whole project management around them just done. > > Yes, doing your own gborg project costs time. You have to maintain > > pages, do your own release cycles with announcement, BETA phase, > > tarballs, packaging and all the nine yards. Being in contrib avoids all > > that in a very convenient way. > > I think Gnome (and KDE) have the right idea. Several independent small > projects that once or twice a year get together and have a big release. > > We could co-ordinate a set of projects (phppgadmin, pgadmin, slony, > jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL. > > We then setup several 'meta' packages. For example, PostgreSQL-lite > might be just the core. PostgreSQL-Advanced might include jdbc, pgadmin, > slony, tsearch, postgis and everything in postgresql-lite. I'd like to agree with this concept, but it falls way short of addressing the problem ... and the problem isn't even pulling things out of contrib ... there are alot of good projects out there that aren't on gforge or in the core distribution that ppl just aren't finding ... a 'Meta Package' doesn't help much, since unless you put *everything* into it that you can possibly find, there is always going to be something missing that someone would find useful ... and if you put everything into it, most ppl would only use a small percentage of what is there ... People keep focusing on how to make a super-meta package ... the problem isn't making one big package that contains it all, it is making sure that what is available is easy to find ... what we need is something like freshmeat that is *only* postgresql software ... Now, Josh et al is working on finishing touches of he Projects web site ... I don't know everything that its able to do, but it does provide a centralized, PostgreSQL specific, place to go to see what is available, as long as ppl use it. ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Magnus Hagander wrote: > > IMHO it's not all that important where the source is developed (core > cvs, gborg etc) - whichever suits the development/release model best > shuold be used (meaning inside core only if it should be released on the > very same schedule as the main backend only). > > What is more important is the exposure of the released versions. I think > it should be possible (and fairly easy) for projects developed outside > the core to get included in the "official download page", meaning go on > the ftp site and mirrors. Today it seems ODBC and pgadmin3 go there, but > pretty much nothing else (not even JDBC?). Perhaps a good structure > there would allow more proejcts to get that kind of exposure, and be > easier to find. > > I quite often get people who claim "there is no this or that" for pgsql > when it's on gborg - simply becauase they didn't find it on the ftp > site. If you go looking, you'll find it on gborg, but if you don't know > where to look it can be hard. Especially for newcomers. I was thinking about CPAN. They have download stuff, but it installs very easily. I wonder if we should allow gborg projects to interface to our configure output in a way that makes it easier for them to be installed. The gborg is easy for development and releasing, but loses in the easy-of-use category sometimes. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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
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.
On Wed, 21 Apr 2004, Bruce Momjian wrote: > I was thinking about CPAN. They have download stuff, but it installs > very easily. I wonder if we should allow gborg projects to interface to > our configure output in a way that makes it easier for them to be > installed. No, because again that requires you to download a large tar ball just to get the build environment? > The gborg is easy for development and releasing, but loses in the > easy-of-use category sometimes. So, what we *should* be looking at it some sort of howto on how to setup an autoconf environment ... the basics aren't too hard, its only when you get into the more complicated stuff that only *large* projects tend to get into that it gets particulary confusing ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Wed, 21 Apr 2004, Rod Taylor wrote: > We have the current issue of people not knowing that projects like > pgadmin exist or where to find the jdbc drivers. Agreed ... but makign one big META package isn't going to fix that ... as someone else suggested, put a README file in the contrib directory that points ppl to projects.postgresql.org ... > These basic components (and others a large segment uses that are well > maintained) should go through a release cycle with the -core including > the platform test/report phase and be prominently listed in the > downloads area and documentation areas -- just as we do for PostgreSQL > proper. *ack* ... now the beta cycle just quadrupled in length ... so we develop for 4 months, and beta for a year while we make sure everyone else's packages work with the -core? Most DBAs that I know will not upgrade based on a .0 release on a production system ... they will wait for at least a .1 release ... between .0 and .1 is when projects like PgAdmin should be doing their testing to make sure that they are good for the new major release ... > Goto http://postgresql.org, now track down the jdbc drivers or how to > use them. To a significant portion of our users this is more important > than CREATE FUNCTION is and in 7.5 jdbc documentation will be much more > difficult to find, but no less important than it used to be. Now, out of all of the PostgreSQL users, what % are using JDBC? What % are using ODBC? What percentage of those using JDBC are also using ODBC? What % of those using PgAdmin are also using ODBC? For that matter, how many ppl using JDBC only want to download the .jar file itself, and not the source code? % of Binary-Only PgAdmin users? ODBC driver? The point of projects.postgresql.org is that if someone *is* looking for an addon, they should be pointed to projects.postgresql.org ... if you try and merge everything into the -core distribution, you are either going to miss something that *someone* wants to use at some point, *or* one helluva large tar file to download ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Wed, 21 Apr 2004, Bruce Momjian wrote: > > > I was thinking about CPAN. They have download stuff, but it installs > > very easily. I wonder if we should allow gborg projects to interface to > > our configure output in a way that makes it easier for them to be > > installed. > > No, because again that requires you to download a large tar ball just to > get the build environment? > > > The gborg is easy for development and releasing, but loses in the > > easy-of-use category sometimes. > > So, what we *should* be looking at it some sort of howto on how to setup > an autoconf environment ... the basics aren't too hard, its only when you > get into the more complicated stuff that only *large* projects tend to get > into that it gets particulary confusing ... There are only a few PostgreSQL developers who can do it, so what are the odds that a single guy who maintains a plugin is going to be able to do it. And you can say it is easy, but it just takes one complex problem to hit you, and with PostgreSQL, and all the shared lib stuff and dynamic loading, lots of it is complex. Let's face it, unbundling is great for release efficiency, but terrible for ease-of-use, and let me also tell you that that is where MySQL shines and is perhaps taking new users from us. No secret there. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Wed, 21 Apr 2004, Joe Conway wrote: > Well, in the case of dblink, consider this: > > - It is used by a fair number of people -- questions are answered on the > lists at least once a week with "see contrib/dblink". A fair # of ppl are using erserver/bsd too ... should we add that in too? > - It is dependent on backend code to the extent that it cannot be built > outside of the contrib folder, unless some backend code is duplicated > in the external project. It also has no build system of its own. k, so this one falls under 'too lazy to build a proper build system' > - dblink-type capability should someday make it into the backend, albeit > in the form of something compliant to the SQL/MED spec. This is > standard functionality in many of the RDBMSs that Postgres users > migrate from, and it is needed by enterprise users. dblink isn't an integrated replication solution, it is a standalone one ... to date, I have not seen one replication solution that solves all the issues, and unless someone comes up with the be all, end all replication solution, none of them should be considered 'part of the backend' ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Joe Conway wrote: > Marc G. Fournier wrote: >> Why is it the core developers responsibility to make sure that an >> application stays in sync with the main tree? Personally, that is giving >> life to software that could just as easily be unused by anyone, but kept >> in the code base because "a commit was made to it less then 6 months ago" >> ... > > Well, in the case of dblink, consider this: > > - It is used by a fair number of people -- questions are answered on the > lists at least once a week with "see contrib/dblink". > > - It is dependent on backend code to the extent that it cannot be built > outside of the contrib folder, unless some backend code is duplicated > in the external project. It also has no build system of its own. Both very valid points and together they indicate a decision point ... > > - dblink-type capability should someday make it into the backend, albeit > in the form of something compliant to the SQL/MED spec. This is > standard functionality in many of the RDBMSs that Postgres users > migrate from, and it is needed by enterprise users. ... which is right here. Either dblink is vital, important and clean enough to move into the main backend code, then let's do it. You claim it is vital and important, but not clean? Then you know what to do. > [...]> > In any case, I don't understand what the driver is to kill contrib. I > fully agree that it should be maintained (meaning that someone other > than core is interested enough to provide patches if non-trivial > maintenance is required to keep it compiling), and stuff that is not > used or suitably licensed should be removed. The contrib build system > ought to be maintained in working order in any case because it makes it > far easier to extend Postgres with your own functions. The driver from my point of view is that some things have been sitting in contrib for quite some time that are neither maintained, nor wanted by anyone. Don't take it personal, I just chose dbmirror and dblink because both fall to some degree into the same usage category as Slony, and both are active projects (I hate shooting at sitting ducks). If we can demonstrate that even projects as vital and complex as these two have a turning point where it says "into the backend or out of contrib", then things like "noupdate" or "userlock" will have a hard time to show any reason to make an exception. > > Anyway, just my 2cents. > > Joe Cool ... found 2 cents :-) Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
On Wed, 21 Apr 2004, Bruce Momjian wrote: > There are only a few PostgreSQL developers who can do it, so what are > the odds that a single guy who maintains a plugin is going to be able to > do it. And you can say it is easy, but it just takes one complex > problem to hit you, and with PostgreSQL, and all the shared lib stuff > and dynamic loading, lots of it is complex. So, put together a developers kit ... you'd need, what, a half dozen files to bootstrap a project with? configure.in, Makefile.in, a README file with the basics on what needs to be modified in Makefile.in, the src/template directory ... If you are looking for a problem to solve, make it easier for developers to setup a proper build environment, don't punish end-users to giving them a bigger package to download ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Bruce Momjian wrote: > I was thinking about CPAN. They have download stuff, but it installs > very easily. I wonder if we should allow gborg projects to interface to > our configure output in a way that makes it easier for them to be > installed. Now that idea I like. The R project also has something similar that allows a standard R command to download, compile, and install their equivalent to contrib packages. They even have an automated system of testing the contributed packages to ensure they work. If the package doesn't meet certain standards, it is automatically dropped from the link list on the download page. See: http://cran.r-project.org/doc/manuals/R-exts.pdf if you're interested. Very impressive, but also a huge amount of work to set up. > The gborg is easy for development and releasing, but loses in the > easy-of-use category sometimes. I agree. Joe
Joe Conway wrote: > Bruce Momjian wrote: > > I was thinking about CPAN. They have download stuff, but it installs > > very easily. I wonder if we should allow gborg projects to interface to > > our configure output in a way that makes it easier for them to be > > installed. > > Now that idea I like. The R project also has something similar that > allows a standard R command to download, compile, and install their > equivalent to contrib packages. They even have an automated system of > testing the contributed packages to ensure they work. If the package > doesn't meet certain standards, it is automatically dropped from the > link list on the download page. See: > http://cran.r-project.org/doc/manuals/R-exts.pdf > if you're interested. Very impressive, but also a huge amount of work to > set up. > > > The gborg is easy for development and releasing, but loses in the > > easy-of-use category sometimes. > > I agree. I am thinking they could untar into a directory under pgsgl/ or have a way to point to a 'configure'-run source tree and pull values from there. If you include pg_config.h, or use Makefile.global, you have almost everything you need to compile your own, including flags, configure checks, and the location of the installation directory. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: > I am thinking they could untar into a directory under pgsgl/ or have a > way to point to a 'configure'-run source tree and pull values from > there. > If you include pg_config.h, or use Makefile.global, you have almost > everything you need to compile your own, including flags, configure > checks, and the location of the installation directory. How hard would it be to have the individual cvs projects such that they could be checked out all in one shot? I'm thinking that if it was easy enough to maintain an up-to-date cvs copy for all the individual projects, then it would be easy to grep the entire mess when making backend changes. That way at least you could determine the extent of the impact when making backend changes. And since they are still individual projects, you don't need to get them all if you're not interested. Joe
On Thu, Apr 22, 2004 at 12:29:36AM -0400, Bruce Momjian wrote: > I am thinking they could untar into a directory under pgsgl/ or have a > way to point to a 'configure'-run source tree and pull values from > there. > > If you include pg_config.h, or use Makefile.global, you have almost > everything you need to compile your own, including flags, configure > checks, and the location of the installation directory. That would work only if they compiled the source themselves, as opposed to using a binary package (which is very common). I'm not sure if installing the postgresql-dev or postgresql-devel package would be enough. If not, maybe pg_config could provide all the necessary info ... -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) Hi! I'm a .signature virus! cp me into your .signature file to help me spread!
On Wed, Apr 21, 2004 at 11:47:11PM -0300, Marc G. Fournier wrote: > On Wed, 21 Apr 2004, Joe Conway wrote: > > - dblink-type capability should someday make it into the backend, albeit > > in the form of something compliant to the SQL/MED spec. This is > > standard functionality in many of the RDBMSs that Postgres users > > migrate from, and it is needed by enterprise users. > > dblink isn't an integrated replication solution, it is a standalone one > ... to date, I have not seen one replication solution that solves all the > issues, and unless someone comes up with the be all, end all replication > solution, none of them should be considered 'part of the backend' ... You are thinking of dbmirror, while Joe talks about dblink. It's orthogonal functionality ... -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Cuando miro a alguien, más me atrae cómo cambia que quién es" (J. Binoche)
Rod Taylor wrote: >> I think most of the current contrib projects are more missing the >> advantage version independence would have for the ease of "sitting" in >> contrib and having the whole project management around them just done. >> Yes, doing your own gborg project costs time. You have to maintain >> pages, do your own release cycles with announcement, BETA phase, >> tarballs, packaging and all the nine yards. Being in contrib avoids all >> that in a very convenient way. > > I think Gnome (and KDE) have the right idea. Several independent small > projects that once or twice a year get together and have a big release. > > We could co-ordinate a set of projects (phppgadmin, pgadmin, slony, > jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL. Maybe not this way, but I like the general idea of "grouping" multiple smaller projects for release and overall project maintenance purposes. CVS has the capability to combine multiple, separate modules into symbolic names. With that, one can create exactly those "meta" checkouts for nightly build systems, which could simply alarm a mailing list of module admins if something goes wrong. Setting up a nightly build agains CVS tip is nothing one would even think of for a simple loadable extension, but if you just have to add the thing to a group and done, Joe Conways concern is mostly answered. Josh, is there anything that remotely sounds like this in the new system you're setting up? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
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>
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
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/
> 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.
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.
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
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
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 #
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
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
> Taking into account that quite a few people have repeatedly stated that > the components in contrib are considered more supported/recommended than > similar solutions found on gborg or any other external site, I suggest > we move the projects dbmirror and dblink to gborg. The rserv contrib > module seems to me to be an early Perl prototype of erserver, nobody is > working on any more. I suggest we drop that entirely. > > Comments/alternatives? I love the idea, but (there is always a "but," isn't there?) I agree with the notion that "contrib" be removed from the main distribution. There is, however, a disconnect between supporting projects and the main system. Take a look at the www.postgresql.org web site. Most people visually filter out the side bars. I've been looking over effectiveness of paid advertisements in the various search engines, and the numbers are clear in that the paid links at the top of the page get the hits while the side hits get almost completely ignored. What I think this means is that people looking for projects will simply filter out any reference to gborg. What would be good, is to bring gborg a little closer to PostgreSQL by putting a link in the main site menu. Rather than: "Download - Mirrors - Lists - Users - Developers - Docs - Search" We could have: "Download - Docs - Lists - Search - Community - Contrib" "Download" would be a unified version of the Download/Mirrors links on the current site. "Docs" Unchanged "Lists" Unchanged "Search" Unchanged "Community" is a unified Users/Developers page. "Contrib" is a link to GBorg.
> I agree with the notion that "contrib" be removed > from the main distribution. There is, however, a > disconnect between supporting projects and the main system. > > Take a look at the www.postgresql.org web site. > Most people visually filter out the side bars. I've > been looking over effectiveness of paid advertisements > in the various search engines, and the numbers are clear > in that the paid links at the top of the page get the hits > while the side hits get almost completely ignored. What I > think this means is that people looking for projects will > simply filter out any reference to gborg. > > What would be good, is to bring gborg a little closer to > PostgreSQL by putting a link in the main site menu. Rather than: What would be even better IMHO is to bring "gborg" a little close to English or a word that makes sense to people visiting the PostgreSQL site. Is it "g-b-org" or "g-borg" or what? Is it a carry-over from the Great Bridge days or some lame hacker reference to the Borg? I understand the reference to Great Bridge, but do newbies? Same goes for "pgfoundry". It might be obvious to the people already using PostgreSQL, but those aren't the people that need help finding something at the web site. What does a foundry have to do with computer projects? We're not associated with an iron-works or Bethlehem Steel, we're a database project trying to attract and keep visitors. If users can't find what they want at our site, they'll find it somewhere else or move on to another product that helps them do what they want. Instead of "gborg projects", why not just call it what it is, "supported projects"? Darren
Josh Berkus wrote: > We can't have *everything* in contrib -- the top 5 GUIs alone would triple the > size of our downloads. So we need to move in the opposite direction -- > putting more stuff in pgFoundry, and letting packagers know that they should > package and include all "mature" projects on pgFoundry if they can. (our > earlier discussion proved that this list cannot realistically designate > "approved" vs. "unapproved" projects). > As I've said on other parts of this thread, my concern with moving everything to gborg/pgFoundry is that it raises the bar in terms of difficulty if we expect every individual project to develop their own infrastructure. What we need to really make that work is to provide an infrastructure similar to Perl's CPAN or the R project's CRAN. Imagine how nice it would be if a relatively new Postgres user could do something like this at a shell prompt: pgFoundry install slony1 pgFoundry install plr pgFoundry install tsearch2 That command would go to a standard URL (but maybe overridden by a configuration option, say to look at a specific mirror, maybe even with backup mirrors specified too) to grab a tarball, download it, untar it to some specific location locally, then run make, make install, make installcheck. The configuration information for the local Postgres install would need to be handy somewhere, support for installcheck, along with all headers (I'd think). I don't know all the details required to make this work, but it would be very useful. Thoughts? Joe
> Taking into account that quite a few people have repeatedly stated that the components in contrib are considered more supported/recommended than similar solutions found on gborg or any other external site, I suggest we move the projects dbmirror and dblink to gborg. The rserv contrib module seems to me to be an early Perl prototype of erserver, nobody is working on any more. I suggest we drop that entirely. > > Comments/alternatives? I love the idea, but (there is always a "but," isn't there?) I agree with the notion that "contrib" be removed from the main distribution. There is, however, a disconnect between supporting projects and the main system. Take a look at the www.postgresql.org web site. Most people visually filter out the side bars. I've been looking over effectiveness of paid advertisements in the various search engines, and the numbers are clear in that the paid links at the top of the page get the hits while the side hits get almost completely ignored. What I think this means is that people looking for projects will simply filter out any reference to gborg. What would be good, is to bring gborg a little closer to PostgreSQL by putting a link in the main site menu. Rather than: "Download - Mirrors - Lists - Users - Developers - Docs - Search" We could have: "Download - Docs - Lists - Search - Community - Contrib" "Download" would be a unified version of the Download/Mirrors links on the current site. "Docs" Unchanged "Lists" Unchanged "Search" Unchanged "Community" is a unified Users/Developers page. "Contrib" is a link to GBorg.
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
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
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
On Thu, 2004-04-22 at 20:09, Marc G. Fournier wrote: > On Wed, 21 Apr 2004, Rod Taylor wrote: > > > I guess that is where we differ in opinion. pgadmin is not addon or an > > enhancement, it is a part of the core project every bit as much as the > > gnome-panel is a part of gnome. Sure, gnome-libs does all the heavy > > lifting, but without the panel most users are lost. > > No it isn't ... you don't need pgadmin, or jdbc, or libpgtcl, or ... to > run a PostgreSQL server ... you need the postgresql core, and, as things > are going, libpq and that is about it ... even psql is becoming less of a > requirement as the support utilities that have been using it move towards > C vs shell wrappers ... Thats actually my point. You don't need epiphany, gnome-panel, gcalc or solitare to have a desktop you can use, but since a majority find those items to be useful they have been included in the default desktop. Those applications are not forced upon users who don't want them, nor are they the only applications available. The perception of PostgreSQL being difficult to use has very little to do with the software itself. The decision has already been made that MySQL is easy and PostgreSQL is difficult at the download page while the user was trying to figure out if the software did what they require. Simply put, nobody on this list is a typical PostgreSQL user. This is shown by the simple fact that they care enough about the software to have joined the list in the first place. A much more common PostgreSQL user is someone who has been given a last minute task to complete and wants to to get it over with as quickly as possible so they can go home. Maybe I'm wrong. But I run into many more of the latter in my average day than I do the former.
Bruce Momjian wrote: > Marc G. Fournier wrote: >>Right, but you don't count ... you aren't an end-user > > True, but what the end users get is nothing because I don't have the > time. No configure, no build environment, very user-unfriendly. > Exactly. Joe
Joe Conway <mail@joeconway.com> writes:
> As I've said on other parts of this thread, my concern with moving
> everything to gborg/pgFoundry is that it raises the bar in terms of
> difficulty if we expect every individual project to develop their own
> infrastructure.
I think that's exactly right. It may be okay for the core project to
decide these little side projects are outside our responsibility ---
but what we had better take responsibility for is a framework within
which it's easy to maintain little side projects. The cost of that
infrastructure is too high to expect the little projects to handle it
individually.
> What we need to really make that work is to provide an
> infrastructure similar to Perl's CPAN or the R project's CRAN.
There's more than one issue. CPAN makes it easy for end users to find
and install little projects. We need that, but we also need to make it
easy for programmers to build and maintain those projects. There was
some speculation earlier in the thread about whether the existing
contrib framework would do as a basis --- I don't know if it can be made
to work, or if it's sufficient, but it might do. In any case we can't
just toss contrib modules over the side and expect that good things will
happen to them when they can't even be built outside the main tree.
The effort to fix that on a retail basis would alone guarantee that
they will be stillborn projects.
regards, tom lane
On Thursday 22 April 2004 13:55, Barry Lind wrote: > I think the solution lies in improving www.postgresql.org. At the end > of the day it doesn't matter where source code lives, what matters is > can people find what they are expecting. Given we know what people are > looking for, that should be front and center on the web site and the ftp > sites. > But of course that solution always stalls out when it comes down to picking which projects get the special treatment of direct links from the main website and which ones stay out of the spotlight. With JDBC you might make the case that the comparable solutions are commercial code (though I suspect some of the commercial distributors might argue that) but with things like admin programs it gets even fuzzier as there are a whole slew of those available as open source projects. If we include them all then we're back to square one, but I've never seen anyone eager to make the decision of which apps are "best" nor anyone terrible willing to let someone else make that decision either. BTW It's not that I am against the idea (if you haven't seen it, check out http://dev.mysql.com/downloads/ for one implementation), it's just that it's a radical departure from "the way things have always been done" and I'm not confident that there would be enough support to make the changes. Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Wed, 21 Apr 2004, Joe Conway wrote: > > On Wed, 21 Apr 2004, Joe Conway wrote: > No, I don't call that lazy, I call it smart. It makes use (reuse) of a > part of Postgres (the contrib build system) that is among its strengths. > Is it your goal to make it harder for people to write their own C > language functions? It makes no sense whatsoever to expect everyone who > wants to extend Postgres to develop their own build system. I'd call > that alot of duplicated effort -- effort better spent more productively. Then, like I mentined to Bruce, we should be looking at some sort of template that those developers can work off of ... downloading an 11Meg file to build a 2k module seems a wee bit excessive, no? > > No one (including me) has ever claimed it is any kind of a replication > system. It is completely different functionality. Sorry, my bad here ... I was mixing dblink with dbmirror ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Tom Lane wrote: > Joe Conway <mail@joeconway.com> writes: > > As I've said on other parts of this thread, my concern with moving > > everything to gborg/pgFoundry is that it raises the bar in terms of > > difficulty if we expect every individual project to develop their own > > infrastructure. > > I think that's exactly right. It may be okay for the core project to > decide these little side projects are outside our responsibility --- > but what we had better take responsibility for is a framework within > which it's easy to maintain little side projects. The cost of that > infrastructure is too high to expect the little projects to handle it > individually. > > > What we need to really make that work is to provide an > > infrastructure similar to Perl's CPAN or the R project's CRAN. > > There's more than one issue. CPAN makes it easy for end users to find > and install little projects. We need that, but we also need to make it > easy for programmers to build and maintain those projects. There was > some speculation earlier in the thread about whether the existing > contrib framework would do as a basis --- I don't know if it can be made > to work, or if it's sufficient, but it might do. In any case we can't > just toss contrib modules over the side and expect that good things will > happen to them when they can't even be built outside the main tree. > The effort to fix that on a retail basis would alone guarantee that > they will be stillborn projects. What if we create a build/ directory as part of install that pg_config.h, Makefile.global, etc, anything a plugin would need, and install it by default. Then, if we give folks an easy way to access them from their own apps and Makefiles, it would solve most of the problems. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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
On Thu, 22 Apr 2004, Bruce Momjian wrote: > OK, I think the number of files needed to build modules is small and I > think can be installed by default in a /build directory. I am thinking > that with a little script help, projects can build apps that look like > like Makefiles used in our core project. This is all I'm saying ... its like when we packaged up our first eRServer ... I didn't require our clients to go out and download PostgreSQL to build it, I pulled in the few files from our build environment into the package so that it could be built independently ... Nice thing was, we were able to hit as many platforms as PostgreSQL did, as building shared libraries and such was all there ready to go ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Bruce Momjian <pgman@candle.pha.pa.us> writes: > What if we create a build/ directory as part of install that > pg_config.h, Makefile.global, etc, anything a plugin would need, and > install it by default. Then, if we give folks an easy way to access > them from their own apps and Makefiles, it would solve most of the > problems. No it wouldn't, because those files *do not work outside the build tree*. There are built-in assumptions about where the Makefiles themselves live relative to the include tree, where the invoking module is relative to all that, etc. Certainly there are a couple of files we need to install that we currently don't, but it's going to take some actual work beyond that to fix the problem. See for example https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112244 and if you're interested try to fix it yourself; it didn't seem trivial when I was poking at it. The specific details aren't especially relevant to this thread, though. What is relevant is that we agree to a commitment that we will make it easy to build modules outside the current Postgres build environment, and that we will have an ongoing commitment to make sure that that keeps working. regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > There's more than one issue. CPAN makes it easy for end users to find > and install little projects. One thing I would like to see is a more direct link to the drivers (e.g. DBD::Pg, JDBC) from the download page. I don't think they need to live in contrib, but having them on the download page right next to the latest PG server files would do wonders. All the maintainers of external projects would have to do is make sure that the link points to where they want it to. For example. look at how MySQL handles the DBD::mysql client (which is hosted at CPAN, not mysql). http://dev.mysql.com/downloads/index.html The download page above has the server links, a few others, and then: "DBI -- for connecting to MySQL from Perl" Clicking on "DBI" gives you a small, clean page that explains what DBI is and gives links to DBI and DBD::mysql, both hosted on cpan.org. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200404230734 -----BEGIN PGP SIGNATURE----- iD8DBQFAiQBDvJuQZxSWSsgRAqn5AJ4pEllgPCiTVfAcrK21r62RgD1tdACg4IHz hAb4LBiqlIMbBF2bsXdZDDI= =xPFb -----END PGP SIGNATURE-----
Tom Lane wrote: > The specific details aren't especially relevant to this thread, though. > What is relevant is that we agree to a commitment that we will make > it easy to build modules outside the current Postgres build environment, > and that we will have an ongoing commitment to make sure that that keeps > working. Agreed. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
> > The specific details aren't especially relevant to this thread, though. > > What is relevant is that we agree to a commitment that we will make > > it easy to build modules outside the current Postgres build environment, > > and that we will have an ongoing commitment to make sure that that keeps > > working. Maybe you should try to mimic apache "apxs" script behavior? It allows to compile, install, configure new modules into apache. pg_config is not convincing at the time: shell> pg_config --includedir-server /usr/local/pg750a/include/postgresql/server shell> ls /usr/local/pg750a/include/postgresql/server ls: /usr/local/pg750a/include/postgresql/server: No such file or directory Too bad, server headers are not installed by default:-( -- Fabien.
On Thu, 2004-04-22 at 23:05, Robert Treat wrote: > On Thursday 22 April 2004 13:55, Barry Lind wrote: > > I think the solution lies in improving www.postgresql.org. At the end > > of the day it doesn't matter where source code lives, what matters is > > can people find what they are expecting. Given we know what people are > > looking for, that should be front and center on the web site and the ftp > > sites. > But of course that solution always stalls out when it comes down to picking > which projects get the special treatment of direct links from the main > website and which ones stay out of the spotlight. With JDBC you might make Most end users don't care if they can choose between 20 administration interfaces. They want to know which one works the best and just use that. Guidelines: 1. Must be fully functional with new release of PostgreSQL on day of PostgreSQL release -- all features. (Admin programs should know how to create and manage all objects). 2. Must function across a majority of platforms that PostgreSQL supports. 3. Must be available for free. Something we could *and will* distribute via CD or could be installed by default. Likewise, source code must be available to ensure it does not become discontinued. 4. Must be high quality -- equivalent to that of PostgreSQL itself. 5. It should be something that a company selling PostgreSQL support would be willing to take on. 6. Must have demonstrated the above prior to inclusion on the download page (gone through a full cycle). 7. They must be willing to change the name to something generic. I.e. PostgreSQL Administration Interface or PostgreSQL Java Connector. In other-words, they need to be willing to be a part of the larger PostgreSQL community. If someone thinks that the JDBC drivers are broken, the JDBC folks should be open to debate on how to solve the issues or otherwise argue that there are no problems. Same as how PostgreSQL itself works. I really don't see this as being any different than deciding which buffer strategy or website style to use. One is better in some way so it becomes a part of the system.
On Fri, 2004-04-23 at 11:02, Rod Taylor wrote:
> On Thu, 2004-04-22 at 23:05, Robert Treat wrote:
> > On Thursday 22 April 2004 13:55, Barry Lind wrote:
> > > I think the solution lies in improving www.postgresql.org. At the end
> > > of the day it doesn't matter where source code lives, what matters is
> > > can people find what they are expecting. Given we know what people are
> > > looking for, that should be front and center on the web site and the ftp
> > > sites.
>
> > But of course that solution always stalls out when it comes down to picking
> > which projects get the special treatment of direct links from the main
> > website and which ones stay out of the spotlight. With JDBC you might make
>
> I really don't see this as being any different than deciding which
> buffer strategy or website style to use. One is better in some way so it
> becomes a part of the system.
>
The difference is that a "better" admin tool is very subjective where as
a buffer strategy is not... or maybe the difference is really that
everyone thinks they are qualified to pick a "better" admin tool, but
very few can really argue as to a better buffer strategy. While I think
your criteria is pretty close to what I would use, I still couldn't pick
which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql...
and even I did I bet some people would have a problem with my choices.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
> 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).
>> 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.
Rod Taylor <pg@rbt.ca> writes: >> The difference is that a "better" admin tool is very subjective where as >> a buffer strategy is not... or maybe the difference is really that >> everyone thinks they are qualified to pick a "better" admin tool, but >> very few can really argue as to a better buffer strategy. While I think >> your criteria is pretty close to what I would use, I still couldn't pick >> which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql... >> and even I did I bet some people would have a problem with my choices. > > If you have a hard time picking between those projects, imagine the > difficulties someone who has never used PostgreSQL has just tracking > down the options available to them. Exactly. MySQL makes no bones about choosing "blessed" projects. I don't think that MySQL AB's MySQL Control Center is the best MySQL GUI, but it's better than the "default" PostgreSQL choice. MySQL shoves a workable solution under the end user's nose. PostgreSQL gives the potential user a wide array of choices, none of which are particularly easy to find. How many GUI tools are listed on GBorg? How many potential users even know to look at GBorg at all? One thing is certain most users aren't going to find psql (probably compiled without readline support) comparable with MySQL Control Center. Not to mention the fact that not having a set of "blessed" tools means that we end up with competing tools. PostgreSQL has several replication toolsets, piles of admin tools, and several competing language bindings for some of the most popular development languages. How many Python bindings does PostgreSQL need? PostgreSQL has some amazing supporting tools, but they are all hidden in an unlighted basement in a locked filing cabinet next to a sign that reads "Beware of the Leopard." > We would not be removing any choices for the user. We're simply > supplying a list of suggested tools that they may have interest in. Exactly. Yes, choosing tools requires some politics, and it will inevitably make some users and developers upset because their projects will get passed over for more popular ones. However, this will certainly help new users that are looking at PostgreSQL for the first time. They will be able to see, right off, what *sort* of tools are available for use with PostgreSQL. Later on as these people become part of the PostgreSQL community they might even find out about alternative tools that they like better. > Getting the user to download PostgreSQL and give it a shot without > becoming frustrated because the "basics" were not available (in an > obvious location) is the first step. PostgreSQL stacks up well as a database. In fact, it rocks. But comparing plain Jane PostgreSQL against other databases and their assorted suite of tools is not going to work in PostgreSQL's favor. Fortunately PostgreSQL has comparable supporting tools as well. Unfortunately no one knows about these tools except for those of us on the PostgreSQL lists. > Step 2 is to inform the user that there are more alternatives available. > I see pgFoundary doing a good job of #2 -- but it is not going to help > with #1 (too much choice is as bad as none at all to a beginner). Precisely. The trick is to promote PostgreSQL and a core set of tools. These tools don't have to be part of PostgreSQL's CVS (or even be available for download) from the postgresql.com site, but they should receive "top" billing. When the end user looks for a GUI, there should be a single solitary GUI that should be the "default" choice. When the end user asks about replication they should be guided to a single solution. In cases where it is difficult to decide what the default case might be--like in the case of replication where the tools you will want to use depends on what you are trying to accomplish--simply point users at the most common scenario and then document that they might need to use other tools to solve different problems. Jason
On Fri, Apr 23, 2004 at 01:05:40AM -0300, Marc G. Fournier wrote: > > This is all I'm saying ... its like when we packaged up our first eRServer > ... I didn't require our clients to go out and download PostgreSQL to > build it, I pulled in the few files from our build environment into the > package so that it could be built independently ... I am the last person in the world to cast aspersions on anyone's packaging, but I'm not sure holding erserver up as a paradigm case of easy compilation outside the main build tree is going to make your argument easier here. A -- Andrew Sullivan | ajs@crankycanuck.ca
On Thu, 22 Apr 2004 pgsql@mohawksoft.com wrote: > "Download - Mirrors - Lists - Users - Developers - Docs - Search" > > We could have: > > "Download - Docs - Lists - Search - Community - Contrib" > > "Download" would be a unified version of the Download/Mirrors links on the > current site. I don't agree with this, since mirrors are web mirrors ... but I do like the 'Contrib' pointing to gborg/projects ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> I don't agree with this, since mirrors are web mirrors ... but I do like
> the 'Contrib' pointing to gborg/projects ...
Yeah, I like the contrib link idea too. Much of the recent discussion
comes down to gborg not being visible enough.
However ... how do we handle things once pgfoundry is online too?
(I suppose two links labeled "Old Contrib" and "New Contrib" might serve
as a forcing function to get projects to migrate over ;-))
regards, tom lane
> "Marc G. Fournier" <scrappy@postgresql.org> writes: >> I don't agree with this, since mirrors are web mirrors ... but I do like >> the 'Contrib' pointing to gborg/projects ... > > Yeah, I like the contrib link idea too. Much of the recent discussion > comes down to gborg not being visible enough. > > However ... how do we handle things once pgfoundry is online too? > > (I suppose two links labeled "Old Contrib" and "New Contrib" might serve > as a forcing function to get projects to migrate over ;-)) > If there is going to be a change, i.e. Great Bridge is going away, and being replaced with pgfoundary, I would suggest that you notify everyone of a date and make it happen. Conversely, on pgfoundary, make a link to gborg calling it "old projects" or something like that. Take a look at this mock-up: http://www.mohawksoft.com/PostgreSQL.html (I am not a good web developer, I just moved a few things around, but I hope you get what I'm trying to say) A good web design makes no assumption that the visitor knows anything about you. Like "mirrors" or "download," whis would tend to confuse first time visitors. A single "Download" link should take the user to a page that explains http/ftp and provides the various source links. Similarly, a "Contrib" should take the user to a single place, gborg now, pgfoundary later. Pgfoundary can then direct them to gborg if the project they are searching for is not there. The main problem with hard to use or "cluttered" web sites is that techies like ourselves tend to put too much up front. Simple is better. Open up a browser window on www.PostgreSQL.org. Don't resize window, assume 1024x768 screen, and maybe 3/4 or 2/3 of the screen is taken by the browser Window. What do you see? You have to scroll to see gborg and the odbc driver and replication, two very important projects. All the visual clues needed to find things need to be seen in that first window or people will not see them. In my screen, the bottom says "User Survey" and "Websites" There are no visual clues that something like gborg would show up if I scrolled down. Yes, you can "The user should just scroll down," but they don't. Period. It is like the first paragraph in a news article, if you don't grap the user there, you won't. Lastly there is grouping and relevence. Why is gborg lower on the page than "User Survey?" Isn't gborg more important to the users than the user survey? Why are there two links to gborg, one under websites and the other under gborg, abd both are under the scroll line. Why is there a link to "mailing list archives" under websites and as a top level link on the menu? All this critisizm aside, I generally like the look of the website, even thought the elephant banner doesn't line up with the PostgreSQL banner :-) It is just that the content and the presentation can be streamlined, taking out redundant links and info, removing logically similar choices i.e. "Download" and "Mirrors," adding "Contrib," and organizing more important stuff at the top and down the middle, with less relvent stuff to the right.
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/>
> > 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.
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