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 ...

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(at)gmx(dot)net

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

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:

> 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(at)gmx(dot)net

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(at)gmx(dot)net

"Marc G. Fournier" <scrappy(at)hub(dot)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(at)hub(dot)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

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(at)candle(dot)pha(dot)pa(dot)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(at)gmx(dot)net

> > 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

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 ...