Re: [pgsql-advocacy] Increased company involvement
От | Andrew Dunstan |
---|---|
Тема | Re: [pgsql-advocacy] Increased company involvement |
Дата | |
Msg-id | 427A4890.7040502@dunslane.net обсуждение исходный текст |
Ответ на | Re: [pgsql-advocacy] Increased company involvement (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [pgsql-advocacy] Increased company involvement
|
Список | pgsql-hackers |
Peter Eisentraut wrote: >Tom Lane wrote: > > >>I want them all in the same CVS basically to avoid any version skew >>issues. They should always have the same branches and the same tags >>as the core, for instance; and it seems hard to keep separate >>repositories in sync that closely. >> >> > >Can you have the same tags across different modules in the same CVS >server? If so, that would work. > > I'm not sure you can tag more than one module at a time. But why would a different module be needed? We split the current single module into different tarballs, don't we? > > >>But packaging them as separately buildable tarballs that depend only >>on the installed core fileset (headers + pgxs) seems a fine idea. >> >> > >If, as it currently appears, we'll end up moving in all of plphp, >pljava, plr, then we might as well be consistent and offer all >procedural languages, with the possible exception of plpgsql, >exclusively as a separate tarball, to be released exactly when a server >release is done. > > One per language, or just an "extra language" pack? >Of course, there are a bunch of build infrastructure issues to be worked >out, but let's settle on the tree structure first and then think about >the build issues. (But don't just move stuff and *then* think about >the build issues.) > > > I agree. I hope we can also still configure/build/test as now - if not you will make my life harder, and it will take lots longer to implement my plan to test PLs in buildfarm. cheers andrew
В списке pgsql-hackers по дате отправления: