Re: inclusions WAS: Increased company involvement

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: inclusions WAS: Increased company involvement
Date: 2005-05-04 14:34:38
Message-ID: 4278DD7E.7050906@fastcrypt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

OK, so the real issue is how do we make pgfoundry work.

My issue is that by pushing all collateral projects off to another site
makes it difficult for people
who are not familiar with the project to find what they are looking for
or even to know what there is to look for.

I'm sure there are other issues as well?

I think it would be useful if we could increase the visibility of core
interfaces such as odbc/jdbc, etc.
1) add in the README the rest of the interface locations
2) create a page on pgfoundry for interfaces. This was proposed when
the interfaces were removed and
somehow did not get done.

I think there's considerable room for creativity here, including some
kind of smart installer that would pull binaries, and or
source from each sub-projects respective locations, but I can also see
that keeping this up to date will be difficult.

Dave
Tom Lane wrote:

>Greg Stark <gsstark(at)mit(dot)edu> writes:
>
>
>>I'm not saying pgfoundry should be shut down. But trying to force
>>projects out into the sterile landscape where they get little use and
>>little support is a death warrant. And unnecessary.
>>
>>
>
>
>
>>I think what I would suggest is going through pgfoundry, and checking in the
>>stable release of any good looking project into the contrib directory of the
>>Postgres distribution.
>>
>>
>
>In other words, decide that pgfoundry is a dead end that will never
>work, and so instead we'll load that maintenance effort back onto the
>core developers.
>
>NO, THANK YOU.
>
>It's entirely likely that we haven't figured out how to make pgfoundry
>work yet. But figure it out we must, or the project-as-a-whole will die
>of its own weight. Not everything can be part of the core.
>
>This isn't directly applicable to the PLs, since those are large efforts
>(and thereby relatively few in number) and they tend to have very
>high-bandwidth linkages to the core server. But to treat everything as
>having those same needs is a recipe for failure.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 7: don't forget to increase your free space map settings
>
>
>
>

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2005-05-04 14:40:56 Re: inclusions WAS: Increased company involvement
Previous Message Andrew Dunstan 2005-05-04 14:30:54 Re: Feature freeze date for 8.1