Marc G. Fournier wrote:

>>
>> The issue is that we have had to wack around the existing PL languages
>> for almost every release to make them work with server changes, and
>> being outside our CVS, plPHP isn't getting that whacking.
>
>
> And the point is, as Tom has pointed out with tsearch2, that even *in*
> CVS, it is a fair amount of work to 'whack' other ppls code ... it
> shouldn't be Tom's responsibility (which is generally what it comes
> down to) to keep someone else's code up to speed with changes in the
> server ...
>
>

Just to reiterate a previous point I have made: buildfarm does build
(and mostly test) things in the core. I have *no* plans at all to make
it test things not in core - currently we get code from one source and
it would be a huge effort to change that. I *do* have plans to make it
run the tests for each PL in core, if they are configured in the build.
So be careful about pushing or keeping out of core things that are now
or will soon get buildfarm testing.

The argument about tarball size I can't take seriously - the plperl
directory for example takes 148k uncompressed in a distribution of 72 Mb.

I agree that contrib needs some considerable cleanup. For example, is
there any good reason not to fold in the crypto stuff?

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Marc G. Fournier wrote:
>
> That is what pgFoundry was setup for ... to give projects the visibiilty
> they would get through the core distribution by making sure they are
> referenced in a central place, but providing the maintainers with direct
> CVS access to make changes to their code in a timely manner .. *shrug*

As a user, I think it's not that PGFoundry projects are
second-class projects because of where they live.
I think they're second-class projects because there is
less visibility into the version computability of those
projects with postgresql compared to those in contrib.


Note that this has nothing to do with a project being "part
of core" - it's largely an documentation/organization issue
of pgFoundry itself.

I think a few changes to pgFoundry would make
packages that live there much more viable.

* I'd like to be able to clearly see what version of a given
pgFoundry project works with which PostgreSQL major release.
I'd like this to be consistent among all pgFoundry versions
so I can very quickly and easily find the package I need.

7.3.X 7.4.X 8.0.X nightly_cvs
pgpool:
plhaskel:
[...]

and within that table, I'd want links to source tarballs,
and possibly whatever RPMs, WindowsInstallers, etc work
and have been tested with the given postgresql release.
It's OK for that table to be mostly empty for projects
that have not been tested with many versions, but if
a link is in there there, it'd be a nice way of
knowing if, for example, plFortran works with old
versions (7.3.X) or if it's been ported to the latest
version.

* I'd like to see the status of pgFoundry projects on
http://www.pgbuildfarm.org/cgi-bin/show_status.pl

Right now I have confidence in most of the contrib
modules largely because I can quickly see if they
succeed or fail.

I'd like any pgFoundry project that is released
into the table described above to also have regression
tests that must pass before they're included in that table.
Ideally, I'd like to be able to see those results for
any released PGFoundry projects run on pgbuildfarm as well
so the status is easily visible.


Even if there's no automated testing involved, I think
it'd be nice if that first table existed; and we could
just trust the developers of each project to put the
right tarballs in the right spots in the table. I'm
wildly guessing that this more limited scope should
be a relatively easy first-step in this direction?

>>>
>>> I thought it was still maintained?
>>
>>
>> Right, but it should be moved out of our CVS, I think.
>
>
> Agreed ... if someone can make the project, I can move the CVS files
> over ... does anyone know who is currently maintaining it though?

I can make the project but I obviously have no desire to maintain it.

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

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

Ron Mayer wrote:

>
>
> * I'd like to see the status of pgFoundry projects on
> http://www.pgbuildfarm.org/cgi-bin/show_status.pl
>
> Right now I have confidence in most of the contrib
> modules largely because I can quickly see if they
> succeed or fail.
>
> I'd like any pgFoundry project that is released
> into the table described above to also have regression
> tests that must pass before they're included in that table.
> Ideally, I'd like to be able to see those results for
> any released PGFoundry projects run on pgbuildfarm as well
> so the status is easily visible.
>

See my cross-posting where I specifically state I have no plans for
buildfarm to test things outside core. It's doable in principle, but
would involve huge amounts of work, for which I at least (as buildfarm's
creator/administrator) would not have time in the foreseeable future.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Mon, May 02, 2005 at 04:53:59PM -0400, Andrew Dunstan wrote:
> See my cross-posting where I specifically state I have no plans for
> buildfarm to test things outside core. It's doable in principle, but
> would involve huge amounts of work, for which I at least (as buildfarm's
> creator/administrator) would not have time in the foreseeable future.

Would you be open to someone else adding the capability? And maybe
mention that on the buildfarm site? (And before anyone asks, no, this
doesn't interest me enough for me to do it :P)
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Jim C. Nasby wrote:

>On Mon, May 02, 2005 at 04:53:59PM -0400, Andrew Dunstan wrote:
>
>
>>See my cross-posting where I specifically state I have no plans for
>>buildfarm to test things outside core. It's doable in principle, but
>>would involve huge amounts of work, for which I at least (as buildfarm's
>>creator/administrator) would not have time in the foreseeable future.
>>
>>
>
>Would you be open to someone else adding the capability? And maybe
>mention that on the buildfarm site? (And before anyone asks, no, this
>doesn't interest me enough for me to do it :P)
>
>

Of course. I won't hold my breath waiting, though :-)

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Marc G. Fournier wrote:
> Agreed ... if someone can make the project, I can move the CVS files
> over ... does anyone know who is currently maintaining it though?

A little research would reveal:

% head contrib/dbmirror/README.dbmirror
DBMirror - PostgreSQL Database Mirroring
================================================== =


DBMirror is a database mirroring system developed for the PostgreSQL
database Written and maintained by Steven Singer(ssinger@navtechinc.com)

(ssinger does submit patches for it on a reasonably regular basis.)

-Neil

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

On Monday 02 May 2005 15:12, Tom Lane wrote:
> "Marc G. Fournier" <scrappy@postgresql.org> writes:
> > On Mon, 2 May 2005, Bruce Momjian wrote:
> >> Marc G. Fournier wrote:
> >>> Then what is the point of having it in CVS? Other then to make are tar
> >>> ball bigger?
> >>
> >> So it can be maintained with other PL languages as the internal API
> >> changes. This is the same reason ecpg is in our CVS because it is tied
> >> to the grammar.
> >
> > Since when? I thought you didn't need the PostgreSQL sources in order to
> > compile pl/PHP, only the installed headers/libraries ... Joshua, has
> > something changed, or did I mis-understand that requirement?
>
> That could be said of *any* of our PLs (at least now that we install all
> server-side headers by default ;-)). I think the real reason we keep
> pltcl etc in the core CVS is exactly what Bruce said: it's easier to
> maintain 'em that way. The problem is that the PLs use all sorts of
> internal backend APIs that we don't want to freeze, and so they are
> constantly being affected by changes in the core backend. Just look
> at the CVS logs for evidence.
>
> Personally, I'm willing to fix the PLs whenever I make a change that
> affects them, but only if they're in core CVS. Dealing with parallel
> changes in two different code repositories is too much of a pain.
> So the folks maintaining non-core PLs take a big hit every release when
> they have to sync with what's happened in the core backend meanwhile.
>

Somewhere I think OS independence is a factor here. Things in the core distro
can generally be figured to work on multiple platforms, especially if the are
getting put through some compiling via the buildfarm. Code on pgfoundry is
probably less likely to work on multiple OS's simply because they may not
have the developer eyeballs to spare for extra platforms. On some projects
like slony this is probably fine, as you can wait for intrest to spring up
before needing to do some work, however other things like odbc or maybe
libpqxx are things that we really do want to be able to work on all our
supported platforms, and having them outside core hurts thier chances.

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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org