Re: inclusions WAS: Increased company involvement - Mailing list pgsql-hackers

From Dave Cramer
Subject Re: inclusions WAS: Increased company involvement
Date
Msg-id 4278DD7E.7050906@fastcrypt.com
Whole thread Raw
In response to Re: inclusions WAS: Increased company involvement  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: inclusions WAS: Increased company involvement
List pgsql-hackers
OK, so the real issue is how do we make pgfoundry work.<br /><br /> My issue is that by pushing all collateral
projectsoff to another site makes it difficult for people<br /> who are not familiar with the project to find what they
arelooking for or even to know what there is to look for.<br /><br /> I'm sure there are other issues as well?<br /><br
/>I think it would be useful if we could increase the visibility of core interfaces such as odbc/jdbc, etc.<br />    
1)add in the README the rest of the interface locations<br />     2) create a page on pgfoundry for interfaces. This
wasproposed when the interfaces were removed and <br /> somehow did not get done.<br /><br /> I think there's
considerableroom for creativity here, including some kind of smart installer that would pull binaries, and or<br />
sourcefrom each sub-projects respective locations, but I can also see that keeping this up to date will be
difficult.<br/><br /> Dave<br /> Tom Lane wrote: <blockquote cite="mid14876.1115184056@sss.pgh.pa.us" type="cite"><pre
wrap="">GregStark <a class="moz-txt-link-rfc2396E" href="mailto:gsstark@mit.edu"><gsstark@mit.edu></a> writes:
</pre><blockquotetype="cite"><pre wrap="">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.   </pre></blockquote><pre wrap=""> </pre><blockquote
type="cite"><prewrap="">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.   </pre></blockquote><pre wrap="">
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

 </pre></blockquote><br /><pre class="moz-signature" cols="72">-- 
Dave Cramer
<a class="moz-txt-link-freetext" href="http://www.postgresintl.com">http://www.postgresintl.com</a>
519 939 0336
ICQ#14675561
</pre>

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Feature freeze date for 8.1
Next
From: "Marc G. Fournier"
Date:
Subject: Re: inclusions WAS: Increased company involvement