Re: [pgsql-advocacy] Increased company involvement - Mailing list pgsql-hackers
From | Marc G. Fournier |
---|---|
Subject | Re: [pgsql-advocacy] Increased company involvement |
Date | |
Msg-id | 20050505151737.L42300@ganymede.hub.org Whole thread Raw |
In response to | Re: [pgsql-advocacy] Increased company involvement (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: [pgsql-advocacy] Increased company involvement
Re: [pgsql-advocacy] Increased company involvement Re: [pgsql-advocacy] Increased company involvement |
List | 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@hub.org Yahoo!: yscrappy ICQ: 7615664
pgsql-hackers by date: