Thread: JDBC split and move ...
Hey all ...
Hopefully that subject caught all of your attentions :)
Over the past few days, -core has spent time discussion issues
concerning GPL vs BSD in our distribution, which led into a discussion on
how "bloated" our distribution has gotten over the years ...
The end result of all of these discussions is that there are
*several* pieces to our distribution that don't need to be *in* the
distribution, and several of *those* that would actually benefit from
being moved out ... and since we now have GBorg (thanks to GreatBridge for
developing it, and Chris Ryan for getting it up and running, as well as
maintaining it), we also have the means to do this while keeping
everything *centralized* ...
Since we have to start somewhere, and since JDBC appears to be
pretty much the most active, we're proposing to start with this one ...
After talking to Chris about how to go about doing the transition,
the plan is to build a Gborg project for it, make sure that Barry Lind
(god, I hope I got my names right here *grin*) has maintainership of the
project in Gborg, and then take and move the jdbc code from the pgsql
CVSROOT and move it into the project CVSROOT, where develoment of the JDBC
driver will continue ...
The main benefit in our eyes to this is that projects that are not
necessarily *tied* to the backend can now maintain their own release cycle
without having to wait for the backend to be ready to go ... if we go
another 8mos with v7.3, there is nothing stop'ng Barry from putting out a
new *official* release of JDBC as its warranted ...
Finally, for those used to ./configure --with-jdbc, well put a
'note' in configure that points ppl at the GBorg project itself, so that
ppl aren't left wondering where it went ...
What we would like to do is move forward on this as soon as v7.2
is branched, which looks like it should be RSN, and once JDBC has been
successfully moved, we'll look at move other sub-projects, like ODBC, onto
GBorg as well ...
Can anyone think of a reason that we haven't been able to think of
where the JDBC driver *has* to be tied to the base distribution itself?
That it can't be downloaded/installed seperately? "it requires libpq"
doesn't count, we're more looking at a requirement for the physical pgsql
server source code, not the libraries that will get installed ...
On Sun, 10 Feb 2002, Peter Eisentraut wrote: > Marc G. Fournier writes: > > > The end result of all of these discussions is that there are > > *several* pieces to our distribution that don't need to be *in* the > > distribution, and several of *those* that would actually benefit from > > being moved out ... > > Agreed. > > > After talking to Chris about how to go about doing the transition, > > the plan is to build a Gborg project for it, make sure that Barry Lind > > (god, I hope I got my names right here *grin*) has maintainership of the > > project in Gborg, and then take and move the jdbc code from the pgsql > > CVSROOT and move it into the project CVSROOT, where develoment of the JDBC > > driver will continue ... > > The only thing I want to fiercely protest about this is the Gborg thing. > The JDBC driver project already has its web site (jdbc.postgresql.org) and > its mailing list, so I don't see why gborg needs to come into the picture > at all. Simply put the CVS root on cvs.postgresql.org, so people that are > used to checking out the pgsql module can simply replace that with the > name of the JDBC driver module. actually, we won't be getting rid of jdbc.postgresql.org, or odbc.* or pgadmin.* ... what I've more looking at/for is the easy collaborrative environment that the web-based frontend on gborg will/does provide ... Barry decides he needs help, recruits something *he* trusts and adds him in without having to go through anyone else ... also, and Chris can correct me on this if I'm wrong, but I believe that those that are "the developers" have the ability to do remote CVS for their work anyway, don't they? > Furthermore, considering that everyone that comes along can open his own > gborg project, things will simply get lost in there. "Official" stuff > should get more prominent treatment. Actually, I can't really see this happening (the getting lost, aspect) ... the only projects that tend to get 'lost' are those that are pretty much dead anyway ... same with sourceforge, your 'busy projects' are more often on the front page ... its the deead ones that you never see ... > Just to make sure: You're not going to put the backend code into a gborg > project, are you? Damn, ya know, until you mentioned it, we hadn't considered it, but since you did bring it up, we'll discuss and let you know *evil grin* ... but I think five words come to mind ... "Not a hope in hell" :)
> the plan is to build a Gborg project for it, make sure that Barry Lind > (god, I hope I got my names right here *grin*) has maintainership of the > project in Gborg, and then take and move the jdbc code from the pgsql > CVSROOT and move it into the project CVSROOT, where develoment of the JDBC > driver will continue ... This seems like a very reasonable idea. I think it would help all of us make the transition if one of you could post a quick intro to GBorg to the list at the appropriate time with some pointers to how to get started. Would this move include migrating user documentation, mailing list & release distribution over from the postgresql.org site, or just be solely for the developers & their source code? -Nick
Marc G. Fournier writes: > The end result of all of these discussions is that there are > *several* pieces to our distribution that don't need to be *in* the > distribution, and several of *those* that would actually benefit from > being moved out ... Agreed. > After talking to Chris about how to go about doing the transition, > the plan is to build a Gborg project for it, make sure that Barry Lind > (god, I hope I got my names right here *grin*) has maintainership of the > project in Gborg, and then take and move the jdbc code from the pgsql > CVSROOT and move it into the project CVSROOT, where develoment of the JDBC > driver will continue ... The only thing I want to fiercely protest about this is the Gborg thing. The JDBC driver project already has its web site (jdbc.postgresql.org) and its mailing list, so I don't see why gborg needs to come into the picture at all. Simply put the CVS root on cvs.postgresql.org, so people that are used to checking out the pgsql module can simply replace that with the name of the JDBC driver module. Quite honestly, I seriously dislike web-based software development infrastructures like sourceforge or gborg. The group has repeatedly spoken out against web-based bug tracking, web-based feature requesting, web-based patch submissions. And let me use this occasion to speak out against having to sign up to some web site before you can join development. Furthermore, considering that everyone that comes along can open his own gborg project, things will simply get lost in there. "Official" stuff should get more prominent treatment. Just to make sure: You're not going to put the backend code into a gborg project, are you? -- Peter Eisentraut peter_e@gmx.net
On Sun, 10 Feb 2002, Nick Fankhauser wrote: > > > the plan is to build a Gborg project for it, make sure that Barry Lind > > (god, I hope I got my names right here *grin*) has maintainership of the > > project in Gborg, and then take and move the jdbc code from the pgsql > > CVSROOT and move it into the project CVSROOT, where develoment of the JDBC > > driver will continue ... > > This seems like a very reasonable idea. I think it would help all of us make > the transition if one of you could post a quick intro to GBorg to the list > at the appropriate time with some pointers to how to get started. > > Would this move include migrating user documentation, mailing list & > release distribution over from the postgresql.org site, or just be solely > for the developers & their source code? yes ... appropriate redirects would be put onto the -jdbc mailing list so that nobody gets lost in the process ...
Mark, OK, now that you have my attention :-) The first thing I would like to understand here is what is the overall plan? You mention things like 'there are serveral pieces...', and 'bloated distribution...'. Before agreeing to make jdbc the guinea pig of some planned reorginization project, I really want to understand the whole plan. What parts of the current source tree go where and what is left? (are we talking about all the pl languages being moved as well?) How is this going to impact documentation? I strongly feel that things like jdbc need to be in the core documentation. Users are going to want/expect IMHO a consolidated set of docs for all of postgreSQL. I don't think we are doing anyone a service if we make them go searching around the internet for various parts of the documentation that may be in different formats, etc. How is this going to impact beta testing? I feel that jdbc gets a lot of testing when the community at large goes through the process of beta testing a new server release. If the proposed change were to occur I would still somehow want the jdbc code bundled as part of the server betas. (sure people can still get it separately, but fewere will). How is this going to impact those who produce binary distributions of Postgres? One thing I see as a result of the proposed change is that jdbc will not get bundled in many of the binary distributions. It is an extra hurdle to have to go pull source from somewhere else and build it and it will no longer appear that jdbc is 'part of' postgres, thus why should it be bundled in a binary distribution any longer? This will be a disservice to end users who will now need to track it down separately. All in all, I am seeing a change being proposed here that doesn't explain what the whole plan is, what the expected benefits are, and what the expected costs are. With what I know (which isn't much at this point) this doesn't seem like it is in the best interest of jdbc or postgres. thanks, --Barry Marc G. Fournier wrote: > Hey all ... > > Hopefully that subject caught all of your attentions :) > > Over the past few days, -core has spent time discussion issues > concerning GPL vs BSD in our distribution, which led into a discussion on > how "bloated" our distribution has gotten over the years ... > > The end result of all of these discussions is that there are > *several* pieces to our distribution that don't need to be *in* the > distribution, and several of *those* that would actually benefit from > being moved out ... and since we now have GBorg (thanks to GreatBridge for > developing it, and Chris Ryan for getting it up and running, as well as > maintaining it), we also have the means to do this while keeping > everything *centralized* ... > > Since we have to start somewhere, and since JDBC appears to be > pretty much the most active, we're proposing to start with this one ... > > After talking to Chris about how to go about doing the transition, > the plan is to build a Gborg project for it, make sure that Barry Lind > (god, I hope I got my names right here *grin*) has maintainership of the > project in Gborg, and then take and move the jdbc code from the pgsql > CVSROOT and move it into the project CVSROOT, where develoment of the JDBC > driver will continue ... > > The main benefit in our eyes to this is that projects that are not > necessarily *tied* to the backend can now maintain their own release cycle > without having to wait for the backend to be ready to go ... if we go > another 8mos with v7.3, there is nothing stop'ng Barry from putting out a > new *official* release of JDBC as its warranted ... > > Finally, for those used to ./configure --with-jdbc, well put a > 'note' in configure that points ppl at the GBorg project itself, so that > ppl aren't left wondering where it went ... > > What we would like to do is move forward on this as soon as v7.2 > is branched, which looks like it should be RSN, and once JDBC has been > successfully moved, we'll look at move other sub-projects, like ODBC, onto > GBorg as well ... > > Can anyone think of a reason that we haven't been able to think of > where the JDBC driver *has* to be tied to the base distribution itself? > That it can't be downloaded/installed seperately? "it requires libpq" > doesn't count, we're more looking at a requirement for the physical pgsql > server source code, not the libraries that will get installed ... > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > >
I agree with Peter's comments here. Why is the gborg thing good for jdbc if it doesn't appear to be wanted by the core server developers? --Barry Peter Eisentraut wrote: > Marc G. Fournier writes: > > >> The end result of all of these discussions is that there are >>*several* pieces to our distribution that don't need to be *in* the >>distribution, and several of *those* that would actually benefit from >>being moved out ... >> > > Agreed. > > >> After talking to Chris about how to go about doing the transition, >>the plan is to build a Gborg project for it, make sure that Barry Lind >>(god, I hope I got my names right here *grin*) has maintainership of the >>project in Gborg, and then take and move the jdbc code from the pgsql >>CVSROOT and move it into the project CVSROOT, where develoment of the JDBC >>driver will continue ... >> > > The only thing I want to fiercely protest about this is the Gborg thing. > The JDBC driver project already has its web site (jdbc.postgresql.org) and > its mailing list, so I don't see why gborg needs to come into the picture > at all. Simply put the CVS root on cvs.postgresql.org, so people that are > used to checking out the pgsql module can simply replace that with the > name of the JDBC driver module. > > Quite honestly, I seriously dislike web-based software development > infrastructures like sourceforge or gborg. The group has repeatedly > spoken out against web-based bug tracking, web-based feature requesting, > web-based patch submissions. And let me use this occasion to speak out > against having to sign up to some web site before you can join > development. > > Furthermore, considering that everyone that comes along can open his own > gborg project, things will simply get lost in there. "Official" stuff > should get more prominent treatment. > > Just to make sure: You're not going to put the backend code into a gborg > project, are you? > >
On Sun, 10 Feb 2002, Barry Lind wrote:
> Mark,
>
> OK, now that you have my attention :-)
>
> The first thing I would like to understand here is what is the overall
> plan? You mention things like 'there are serveral pieces...', and
> 'bloated distribution...'. Before agreeing to make jdbc the guinea pig
> of some planned reorginization project, I really want to understand the
> whole plan. What parts of the current source tree go where and what is
> left? (are we talking about all the pl languages being moved as well?)
Over time, anything that is not tied directly into the backend code ...
eventually, I'm even looking at some way of splitting off
interfaces/libpq, since I'm itred of having to download and install an
8Meg distrubtion ust to getl ibpq to compile PHP4 with :(
> How is this going to impact documentation? I strongly feel that things
> like jdbc need to be in the core documentation. Users are going to
> want/expect IMHO a consolidated set of docs for all of postgreSQL. I
> don't think we are doing anyone a service if we make them go searching
> around the internet for various parts of the documentation that may be
> in different formats, etc.
Actually, we're also discussing moving docs into a 'docs project' ...
> How is this going to impact beta testing? I feel that jdbc gets a lot
> of testing when the community at large goes through the process of beta
> testing a new server release. If the proposed change were to occur I
> would still somehow want the jdbc code bundled as part of the server
> betas. (sure people can still get it separately, but fewere will).
The point is to *reduce* the size of the bundles, not increase them ...
with all the changes that went into JDBC, especially since you took it
over, you could have done at least two full releases before v7.2 was
released, for bug fixes and new features that didn't rely on v7.2 itslf
...
> How is this going to impact those who produce binary distributions of
> Postgres? One thing I see as a result of the proposed change is that
> jdbc will not get bundled in many of the binary distributions. It is an
> extra hurdle to have to go pull source from somewhere else and build it
> and it will no longer appear that jdbc is 'part of' postgres, thus why
> should it be bundled in a binary distribution any longer? This will be
> a disservice to end users who will now need to track it down separately.
but, it shouldn't be 'bundled in' ... take a look at the RPMs:
postgresql# ls
postgresql-7.2-1PGDG.i386.rpm postgresql-jdbc-7.2-1PGDG.i386.rpm
postgresql-python-7.2-1PGDG.i386.rpm postgresql-tk-7.2-1PGDG.i386.rpm
postgresql-contrib-7.2-1PGDG.i386.rpm postgresql-libs-7.2-1PGDG.i386.rpm
postgresql-server-7.2-1PGDG.i386.rpm postgresql-devel-7.2-1PGDG.i386.rpm
postgresql-odbc-7.2-1PGDG.i386.rpm postgresql-tcl-7.2-1PGDG.i386.rpm
postgresql-docs-7.2-1PGDG.i386.rpm postgresql-perl-7.2-1PGDG.i386.rpm
postgresql-test-7.2-1PGDG.i386.rpm
its its own distribution ... right now, under FreeBSD ports, you want
*anything*, you hvae to install *everything* ... I so want to be able to
go to /usr/ports/database/pgsql-client and install libpq.a so tht I ca
build PHP4, instead of having to install >5Meg of binares just go get
~150k of libraries .. or be able to go to /usr/ports/java/pgsql-jdbc ...
The point is that if the backend source code isn't a requiremetn for
building jdbc, then I should be able to download it and compile it without
the source code for the backend ...
> All in all, I am seeing a change being proposed here that doesn't
> explain what the whole plan is, what the expected benefits are, and what
> the expected costs are.
>
> With what I know (which isn't much at this point) this doesn't seem like
> it is in the best interest of jdbc or postgres.
Which is why we haven't just gone and done it :)
The whole plan:
remove as much from the 'backend source distributions' as is
possible in order to a) reduce overall packaging size and b) make it
easier for someone wanting JDBC drivers (or ODBC drivers, or python
interface, or etc etc) to be able to build those without having to
download and install everything they do not require ...
Expected benefits:
let's just use an example here that is very "real world" ... I
have a machine that contains 200+ virtual machines ... each of those
'machines' has a requirement for libpq.* to be installed, for PHP4, but
none of them need *anything* else from the distribution ... so that is the
default configuration. Out of those 200+ machines, I've had several
clients start using Java+Tomcat+JDBC for various projects, so to add that
functionality on for them, in order to 'stick with ports' for stuff like
this, I have to re-download (if it isn't already cached) the latest full
distribution (~9Meg) *and* compile the *whole* backend *and* install all
the binaries just to get the jdbc.jar file ... as opposed to just going
into /usr/ports/java/pgsql-jdbc and downloading the jdbc source
distribution, and compiling it against my already existing libpq file ...
Plus, on top of that, didn't just jsut announce new jar files for v7.1 and
v7.2 ... or, rather, they will work under both? So, right now, if I
wanted to compile from source, I have to download the whole v7.2, build
that and hte jdbc drivers, and then manually copy out jdbc.jar ...
Expected Costs:
From my perspective, where I maintain a slew of client machines
with a centralized database server ... reduced time spent downloading and
compiling to get the piece (or pieces) I require on the client machine
As for the 'fewer ppl testing' argument ... how do you figure?
Right now, the only ppl that are testing are those that use/need jdbc ...
if you were to actually *release* 3x for every release of PostgreSQL, and
based on ppl being more apt to *use* a released product vs one just in
beta, the JDBC driver would most likely get *more* use and *better*
testing outside of the PgSQL main stream distribution then in it ...
and this is one of the key reasons why -core started to go down
this route ... there are several *good* projects that are independent of
the backend whose release cycles are tied inot the backends release cycle,
but that *aren't* keyed to it ...
Marc G. Fournier writes: > Over time, anything that is not tied directly into the backend code ... > eventually, I'm even looking at some way of splitting off > interfaces/libpq, since I'm itred of having to download and install an > 8Meg distrubtion ust to getl ibpq to compile PHP4 with :( You don't have to. Just compile it once and install it as many times as you need it. -- Peter Eisentraut peter_e@gmx.net
Marc G. Fournier writes: > Actually, we're also discussing moving docs into a 'docs project' ... Oh, I can see it now: half a dozen different projects with different release cycles all scribbling on top of each other into a single documentation source. And when one of those projects has a release, it has the option of not shipping any documentation, or taking whatever happens to be in the docs project right now, not knowing what the state of the rest of the documentation is. Separating documentation from what it is documenting is just such a bad idea, I won't even consider it. -- Peter Eisentraut peter_e@gmx.net
"Marc G. Fournier" <scrappy@hub.org> writes:
> Over time, anything that is not tied directly into the backend code ...
> eventually, I'm even looking at some way of splitting off
> interfaces/libpq, since I'm itred of having to download and install an
> 8Meg distrubtion ust to getl ibpq to compile PHP4 with :(
Note that this is Marc's idea and is not necessarily shared by the rest
of core (it's certainly not shared by me). IMHO a server that you
can't talk to is pretty useless, and therefore libpq and psql (at least)
must be part of the minimal package.
It seems to me that Marc's real complaint could be addressed by a make
target that builds a libpq-only source tarball. That does not mean that
the source files involved have to be separated into a different CVS tree
or a different full-distribution tarball. The RPM builds are already
doing similar things quite successfully.
I can see some value in splitting JDBC out: you guys seem to be moving
pretty quickly and could make good use of the ability to release JDBC
more frequently than the backend is released. However, if you don't
want to do that, I'm certainly not going to vote to force you to become
a separate distribution.
regards, tom lane
On Sun, 10 Feb 2002, Tom Lane wrote: > "Marc G. Fournier" <scrappy@hub.org> writes: > > Over time, anything that is not tied directly into the backend code ... > > eventually, I'm even looking at some way of splitting off > > interfaces/libpq, since I'm itred of having to download and install an > > 8Meg distrubtion ust to getl ibpq to compile PHP4 with :( > > Note that this is Marc's idea and is not necessarily shared by the rest > of core (it's certainly not shared by me). IMHO a server that you > can't talk to is pretty useless, and therefore libpq and psql (at least) > must be part of the minimal package. > > It seems to me that Marc's real complaint could be addressed by a make > target that builds a libpq-only source tarball. That does not mean that > the source files involved have to be separated into a different CVS tree > or a different full-distribution tarball. The RPM builds are already > doing similar things quite successfully. for libpq and psql, that I have no problem with, sorry, kinda got over-zealous in my para above :) as for jdbc/odbc and other such ... if a make target is doable there too, so be it ... my real beef here is that I can't get one piece I need without having to download the whole thing ... I think the 'seperate release cycle' would be of a real benefit also, to those projects, but if those maintaining don't feel the same, I'm not going to argue until I'm blue in the face over it ...
I can see some value in splitting JDBC out: you guys seem to be moving
pretty quickly and could make good use of the ability to release JDBC
more frequently than the backend is released. However, if you don't
want to do that, I'm certainly not going to vote to force you to become
a separate distribution.
regards, tom lane
I have to agree with Tom here, I don't see anything wrong with the way
things are now, except that we would like to release more often.
I would vote for a separate release schedule
Dave
Marc G. Fournier wrote > > and this is one of the key reasons why -core started to go down > this route ... there are several *good* projects that are independent of > the backend whose release cycles are tied inot the backends release cycle, > but that *aren't* keyed to it ... > I meant to make a comment on this in my last mail note. It isn't true that jdbc is independent of the backend release cycle. In the last two releases that I have been involved in there have been changes in the backend that have required changes to jdbc. Thus a new jdbc release has been necessary for both 7.1 and 7.2. (generally this is due to changes in the core pg_* tables). In the current environment there isn't any reason that we couldn't already have more frequent releases of jdbc than the backend. But there are reasons why I beleive that at a minimum a new release of jdbc needs to correspond to each new server release. It seems to me that there are two reasons this whole proposal is being discussed: 1) More frequent releases for jdbc 2) Smaller more modular source bundles I would argue 1 can be achieved today without any changes. I feel that 2 is the issue that is really driving this discussion. Couldn't this be achieved in some other way, without the complete separation that is being suggested? Wouldn't it be possible to have a cvs structure that looked something like this: pgsql - server - jdbc - odbc - etc server - symlink to pgsql/server jdbc - symlink to pgsql/jdbc odbc - symlink to pgsql/odbc ... Where pgsql, server, jdbc, odbc would each then be a module that could be checkedout via cvs. So if you wanted everything you would just pull from pgsql (cvs checkout pgsql), or you could just pull jdbc (cvs checkout jdbc). I haven't thought about how configure would work in this environment, but I would think that there would be a top level configure at the pgsql level that would have options like --with-java, --with-server, etc, while each individual component would have it's own configure??? not sure here. As I stated before there are benefits of having a consolidated source tree (documentation, binary distributions, testing) that I am reluctant to give up just to achieve a smaller source bundle. thanks, --Barry
Dave Cramer wrote: > > I have to agree with Tom here, I don't see anything wrong with the way > things are now, except that we would like to release more often. > > I would vote for a separate release schedule > We could have a more frequent release cycle today for jdbc if we wanted. There is nothing preventing us from creating a branch for a jdbc release to be done between 7.2 and 7.3. But as I have stated in a previous mail note, there are generally dependences between jdbc and the backend that will likely require at a minimum a new jdbc release for each backend release. Also what happens when we get to the point where we have a java procedural language in the server? Then the line that appears very clear between backend and jdbc code gets very blurred. (fyi, this is something that I know two different people are working on and might get done in the 7.3 timeframe). thanks, --Barry
> > It seems to me that Marc's real complaint could be addressed by a make > > target that builds a libpq-only source tarball. That does not mean that > > the source files involved have to be separated into a different CVS tree > > or a different full-distribution tarball. The RPM builds are already > > doing similar things quite successfully. > > for libpq and psql, that I have no problem with, sorry, kinda got > over-zealous in my para above :) > > as for jdbc/odbc and other such ... if a make target is doable there too, > so be it ... my real beef here is that I can't get one piece I need > without having to download the whole thing ... I think the 'seperate > release cycle' would be of a real benefit also, to those projects, but if > those maintaining don't feel the same, I'm not going to argue until I'm > blue in the face over it ... What would be real interesting is an interfaces CVS with everything _but_ libpq. Most interfaces rely on libpq, and the API doesn't change much, and ODBC/JDBC are usually backward compatibile. There is some logic that non-libpq interfaces could stand on its own with its own release cycle. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Peter Eisentraut wrote: > Marc G. Fournier writes: > > > Over time, anything that is not tied directly into the backend code ... > > eventually, I'm even looking at some way of splitting off > > interfaces/libpq, since I'm itred of having to download and install an > > 8Meg distrubtion ust to getl ibpq to compile PHP4 with :( > > You don't have to. Just compile it once and install it as many times as > you need it. I think we need to separate packaging issues from CVS split issues. There is no reason we can't have an /interfaces tar file. It doesn't require a CVS split. Now, if you want to release /interfaces at different intervals from backend code, that could require a CVS split. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Barry Lind writes: > Where pgsql, server, jdbc, odbc would each then be a module that could > be checkedout via cvs. So if you wanted everything you would just pull > >from pgsql (cvs checkout pgsql), or you could just pull jdbc (cvs > checkout jdbc). > > I haven't thought about how configure would work in this environment, > but I would think that there would be a top level configure at the pgsql > level that would have options like --with-java, --with-server, etc, > while each individual component would have it's own configure??? not > sure here. There are a number of ways to make this work. The Cygnus (a.k.a. GCC) tree and the KDE project are examples. You have a number of related projects in sibling directories. Each project uses a GNU-style configure/make process. At the top of that tree you have a master configure script or makefile, either hand-crafted (Cygnus) or automatically generated (KDE). The user runs the top configure with the options he'd like (e.g., --with-pgport=6543 --enable-locale) and the top-level configure runs each present lower configure in turn with those options. There's also a top-level makefile that invokes all the lower-level ones. This gives you a certain degree of flexibility and simplification. Each configure script only has to deal with a subset of the problem space (e.g., Java, Perl). People only have to check out the stuff they want. You can bundle distributions in different ways. Note, however, that in spite of this, there's still only one release of GCC (even though some language front-ends move faster than others at times) and there's only one release of KDE. I think the consequences of the perceived faster development in the JDBC driver should be weighed carefully. Firstly, the fast development followed a long period of relative inactivity. Sooner or later, activity will level off because all the known and easy problems have been solved. Secondly, faster development is a matter of perspective. Consider the total level of development in the source tree. When there are enough changes, why not make a full release that features more JDBC changes than backend changes? (Heck, why not make full releases more often period.) Overall, I'm open to structural improvements, but like Barry I'd like to see the full plan first, not move JDBC off and see where it goes. -- Peter Eisentraut peter_e@gmx.net
> I meant to make a comment on this in my last mail note. It isn't true > that jdbc is independent of the backend release cycle. In the last two > releases that I have been involved in there have been changes in the > backend that have required changes to jdbc. Thus a new jdbc release has > been necessary for both 7.1 and 7.2. (generally this is due to changes > in the core pg_* tables). In 7.2, MD5 encryption also required jdbc changes. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> -----Original Message----- > From: Peter Eisentraut [mailto:peter_e@gmx.net] [...] > I think the consequences of the perceived faster development > in the JDBC > driver should be weighed carefully. Firstly, the fast development > followed a long period of relative inactivity. Sooner or > later, activity > will level off because all the known and easy problems have > been solved. Right on.
Reviewing the list this morning, there seem to be some emerging common threads. All of them support some limited organizational changes, and none support moving to GBorg as the development infrastructure: 1) The ability for users to pick & choose among desired components is good. - This is more of a packaging issue. It would require some effort on the part of the "make" gurus, but it seems reasonable to support several standard component suites & even to make the process fully customizable. This packaging work would be required with the GBorg plan as well. 2) An independent release cycle is mostly good and might encourage faster development. - This is an organizational issue that any component development group could handle themselves if the community as a whole supported it. It's a bit more work, but regardless of the development infrastructure, this work would need to be done. Speaking as a user, the release cycle is currently very important to me given the relative "youth" of JDBC, but it is likely to be of little value a year from now when JDBC has matured a bit. 3) Integration of documentation between all components is good, and the documentation should be in good order before the release of any component. -Again, more of an organizational issue. Since the documentation tends to be as modular as the components, it should be reasonable to create a "make" process that pulls clean documentation out from each most current component release. 4) Nobody seems excited about switching to GBorg as the development infrastructure. -Most people however are cautiously supportive of the goals that Marc had in mind when proposing a change. As a user, I'd like to see a nice, clean separation between components, documentation that corresponds to the components in the same modular fashion, and independent release cycles. As a user, I also don't care that much about the development infrastructure, so my comments about GBorg are more of an observation of others than a valid opinion. This is why the idea seemed reasonable to me at the outset, but as a non-developer, I can only judge the goals with validity. My vote really shouldn't count when it comes to the methods. -Nick
On Mon, 11 Feb 2002, Peter Eisentraut wrote: > Barry Lind writes: > > > Where pgsql, server, jdbc, odbc would each then be a module that could > > be checkedout via cvs. So if you wanted everything you would just pull > > >from pgsql (cvs checkout pgsql), or you could just pull jdbc (cvs > > checkout jdbc). > > > > I haven't thought about how configure would work in this environment, > > but I would think that there would be a top level configure at the pgsql > > level that would have options like --with-java, --with-server, etc, > > while each individual component would have it's own configure??? not > > sure here. > > There are a number of ways to make this work. The Cygnus (a.k.a. GCC) > tree and the KDE project are examples. You have a number of related > projects in sibling directories. Each project uses a GNU-style > configure/make process. At the top of that tree you have a master > configure script or makefile, either hand-crafted (Cygnus) or > automatically generated (KDE). The user runs the top configure with the > options he'd like (e.g., --with-pgport=6543 --enable-locale) and the > top-level configure runs each present lower configure in turn with those > options. There's also a top-level makefile that invokes all the > lower-level ones. > > This gives you a certain degree of flexibility and simplification. Each > configure script only has to deal with a subset of the problem space > (e.g., Java, Perl). People only have to check out the stuff they want. > You can bundle distributions in different ways. > > Note, however, that in spite of this, there's still only one release of > GCC (even though some language front-ends move faster than others at > times) and there's only one release of KDE. If we could implement something like this, where I could download *just* libpq to a box, or *just* jdbc to a box, and build it without all of the "extras", then I'll most happily shut up :) That is my only *major* beef with the way we are doing it now, it doesn't *parcel* well at the source level ...