Re: [pgsql-advocacy] Increased company involvement

Поиск
Список
Период
Сортировка
От Marc G. Fournier
Тема Re: [pgsql-advocacy] Increased company involvement
Дата
Msg-id 20050505151737.L42300@ganymede.hub.org
обсуждение исходный текст
Ответ на Re: [pgsql-advocacy] Increased company involvement  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [pgsql-advocacy] Increased company involvement  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
Re: [pgsql-advocacy] Increased company involvement  (Peter Eisentraut <peter_e@gmx.net>)
Re: [pgsql-advocacy] Increased company involvement  (Robert Treat <xzilla@users.sourceforge.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [ADMIN] A real puzzler: ANY way to recover?
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Views, views, views! (long)