Re: Time to work on Press Release 8.0 - Mailing list pgsql-advocacy

On Tue, 17 Aug 2004, Andreas Pflug wrote:

> Magnus Hagander wrote:
>
>
>>
>> I've sure heard a lot of people saying there is no decent GUI and/or
>> web-GUI to admin a pgsql server. Then I show them pgadmin or phppgadmin,
>> and they're stunned. But they just didn't *find* it.
>
> I only can stress what Magnus says.
> The pginstaller will partially fix this for win32, but the issue is basically
> the same for all os, and other tools and important modules (Slony-1).
>
> Having one-stop-shopping for users, there's also the issue for
> one-stop-bugreporting. I already saw several pgadmin3 bugs posted to -hackers
> or -bugs; although we provide a prominently placed menu entry for bug
> reporting, people still don't read it <sigh>
>
> It's not easy enough to find out how to post pgsql bugs. Can't we have a
> "Bugs" link in the line where "Download", "Mirrors" reside?

I believe I've asked this before, but I may be mis-remembering ...

What would it take to have a more 'dynamic' build system?  And now that
I've worded that badly, let me explain what I'm "thinking" ...

From a packagers perspective, smaller chunks are easier to deal with ...
at least in so far as FreeBSD ports is concerned ... having to download a
12Meg tar ball to pull out <1Meg of source files for a build is a waste
... optimally, there would be a 'libpq.tar.gz' tar file that could be
downloaded to give the client libraries, that would be used to build
everything else ...

Now, what would it take to make it possible to pull in external packages
and make a 'mega-distribution'?

For instance, when I build a release, there is a .tar.gz file that is
created that includes *everything*, and there is a -base.tar.gz,
-contrib.tar.gz, etc ... would it be possible to have part of the make
target pull down a copy of, say, slony and include that under contrib?

I can easily do the cvs login for Slony's CVSROOT, so that a cvs checkout
would work, and I can easily put that into the proper directory ... but
the infrastructure is not that to, say, have a ./configure --enable-slony
or something like that option if contrib/slony exists ...

I don't know if this is possible or not ...

The same could apply for JDBC, pgadmin3, etc, etc ... whatever is deemed
appropriate ... each project would still have their own development
environments on pgfoundry, their own list of developers and access
controls, and their own release cycles *between* PostgreSQL (the server)
releases ... but, say, when we go into feature freeze/beta for the main
server, they are required to branch and provide us with the *stable*
branch TAG that is meant for the release ... if they can't, then that
package would be quickly pulled from the distribution for that release ...

Is this something that could be done?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664