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
> > 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 ke
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Tom Lane) wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> 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 in
> "Marc G. Fournier" <[EMAIL PROTECTED]> 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.
>
>
"Marc G. Fournier" <[EMAIL PROTECTED]> 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 ...
On Thu, 22 Apr 2004 [EMAIL PROTECTED] 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 a
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
> packa
Rod Taylor <[EMAIL PROTECTED]> 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 bet
>> 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
> 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 cr
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 matt
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. Gi
> > 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 ke
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 ke
-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
liv
Bruce Momjian <[EMAIL PROTECTED]> 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 s
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 pr
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 har
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> 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.
>
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
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
Joe Conway <[EMAIL PROTECTED]> 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 righ
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
---(end of broadcast)--
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-lib
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 t
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
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
> 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
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 pgF
> 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 effectiv
> 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
> modu
Kris,
Thank you. I objected to having the jdbc code moved out of the base
product cvs tree for some of the reasons being discussed in this thread:
how are people going to find the jdbc driver, how will they get
documentation for it, etc.
I think the core problem is that some people view post
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
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 alm
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
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
> > pro
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
> 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 he
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.
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 unde
Hello,
I believe that one problem with the contrib is that in order to build
most of the contrib modules you need
the PostgreSQL source. That is silly. If I have PostgreSQL installed
with all headers, I should be able to
download a PostgreSQL project app (pgAdmin whatever) and just build it
ag
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
p
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 th
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
> everythin
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, config
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 l
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 sim
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
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?
>
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
> > ins
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 directo
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 requ
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
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
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).
>
> Wh
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 c
> 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
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
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
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 ba
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 si
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 o
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
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 w
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Wed, 21 Apr 2004, Tom Lane wrote:
>> "Joshua D. Drake" <[EMAIL PROTECTED]> 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 var
> -Original Message-
> From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
> Sent: 21 April 2004 19:16
> To: Jan Wieck
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] contrib vs. gborg/pgfoundry for
> replication solutions
>
> Hello,
>
> My person
c: 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
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 t
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.
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, Joshu
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
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 re
On Wed, 21 Apr 2004, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> 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'
"Joshua D. Drake" <[EMAIL PROTECTED]> 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 i
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 bac
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
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 co
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 see
78 matches
Mail list logo
