From: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [pgsql-advocacy] Increased company involvement |
Date: | 2005-05-05 18:25:45 |
Message-ID: | 20050505151737.L42300@ganymede.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-hackers |
On Thu, 5 May 2005, Tom Lane wrote:
>> Can I suggest that we focus on PLs first and foremost, since that will
>> allow us to get stuff like pl/PHP, pl/Java, pl/J(?), and pl/R in place,
>> and then ramp up other stuff as time permits?
>
> Agreed.
'k, if there are no disagreements ... I can't see there being much we need
to do to "get started" ... I don't need a "fully working and buildable
package" to do the initial module load in CVS, so I think its pretty safe
to say "anyone that has an "external PL" that they wish to have as a
module (not integrated with the core distribution, only on the core CVS
server), please send me a tar file of what they wish to have imported, and
I can get that done. Once that is done, I can work up the mk-snapshot
script to build 'snapshot distributions' of the various modules as well
...
> This is not to say that we might not want to adjust our distribution
> setup so that it's easier for people to find 'em --- that is, we could
> put JDBC/ODBC tarballs on the main ftp servers. But I don't see the
> need for any coupling inside CVS.
Hrmmm, that would be a bit more difficult, but I could extend the
distribution build scripts so that they do an export from CVSROOTs housed
on pgfoundry based on code "at the time of" the distribution build ...
hrmmm, even better ...
mk_snapshot would build off of -HEAD, which is what it does now
when we go beta for the core distribution, external projects would be
required to tag/branch their own branch equivalent to the one we are
basing a release off of, so that what we are pulling is less of a moving
target then the -HEAD would potentially be ... basically, there has to be
a tag/branch equivalent to that for which we are about to release ...
it wouldn't be much more work on our side, since I should be able to
easily script for it, it would just mean that projects like
JDBC/libpqxx/ODBC would need to setup an appropriate tag at varoius points
in development so that they get included ...
So, what we'd be looking at is pretty much any driver/interface
could potentially be included, and if the tag doesn't exist (ie. nobody is
maintaining it), it wouldn't be included in that "release" ...
Sound reasonable?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2005-05-05 19:04:03 | Re: [pgsql-advocacy] Increased company involvement |
Previous Message | Andrew Dunstan | 2005-05-05 18:17:12 | Re: [pgsql-advocacy] Increased company involvement |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2005-05-05 18:58:01 | Re: Views, views, views! (long) |
Previous Message | Tom Lane | 2005-05-05 18:19:15 | Re: A real puzzler: ANY way to recover? |