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
packageI 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
andhave been tested with the given postgresql release. It's OK for that table to be mostly empty for projects that
havenot 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
mustpass before they're included in that table. Ideally, I'd like to be able to see those results for any released
PGFoundryprojects 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?
