Skip site navigation (1) Skip section navigation (2)

Re: Time to work on Press Release 8.0

From: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
To: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-advocacy(at)postgresql(dot)org
Subject: Re: Time to work on Press Release 8.0
Date: 2004-08-16 23:41:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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 (
Email: scrappy(at)hub(dot)org           Yahoo!: yscrappy              ICQ: 7615664

In response to

pgsql-advocacy by date

Next:From: Andreas PflugDate: 2004-08-17 01:20:48
Subject: Re: Time to work on Press Release 8.0
Previous:From: Josh BerkusDate: 2004-08-16 22:11:26
Subject: Need PG internationalization guru

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group