Re: JDBC split and move ...

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