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?
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
