Re: JDBC 4 Compliance

I don't think this has anything to do with Dave's amount of time, and I
think he's done a remarkable job of keeping the lights on.

>> As an aside, I think it's interesting that the longer this thread goes,
>> the more it proves the point that it's easier to just go do it yourself.
>
> Define "it".  What specifically is easier to accomplish on your own?

Ok. I'll bite. I'll answer your questions wrt adding a second XA
implementation.

* It's easier to modify the driver to fit your needs and work with your
own git repository than it is to push the change upstream.

* There's little need to push the change up stream because face it,
there's not much action going on in the upstream repository.

* Since there's no action in the upstream repo, the cost of merging
upstream remotes is lower than the cost of prepping a branch for a pull
request.

> What goals and restrictions are you setting for re-inventing the wheel?

I needed PostgreSQL to be a stable JDBC XADataSource in GlassFish 3.1,
where I can't turn interleaving off in the transaction manager.

> How much of the existing work are you going to simply copy?

Pretty much just the method signatures...

> The thing bothering you right now is politics which, by broad definition, is
> the resolving of differences between individuals.

How bold (and incorrect) of you to assume you know what's bothering me.

> Of course "do[ing] it
> yourself" is going to resolve the political issues since there is no more
> "between individuals" aspect to deal with anymore.  It is also a big cop-out
> from the perspective of the pre-existing community.  Sure, go off on your
> own and when you come back in a couple of years maybe what you did will be
> what we need/want - but since you weren't interacting with us in the
> meantime who knows.

I sure hope you weren't directing that at me. I (and others in my
office) have willingly debated, implemented, and jumped through the
required hoops to get an interleaving-capable XA implementation merged
into the mainline driver. We're quite pleased with the results. Thanks
to the debate on the list, the implementation was able to rapidly mature
and improve. It's been stable (on glassfish 3.1.2.2) for us for several
months now, and we have the community on this list to thank for
challenging our initial ideas.

It would have been *far* easier for us to maintain a downstream branch
on github with our implementation rather than try to push it upstream.

I don't want to see this project fragment. I believe it would benefit
the community to have a confluence around a central project with a
structure to coordinate and accept things which progress the status quo.

>  Maybe you don't care if it works for anyone else but
> yourself and a few others who happen to stumble upon it (and would simply be
> thrilled if indeed it becomes the new standard somehow) and while that isn't
> necessarily a bad/wrong position to take it is by some definitions selfish;
> and regardless is anathema to those, like Dave, who because of the community
> focus cannot simply throw everything away and start fresh; and definitely
> doesn't want to make things easier by taking the politics out of the
> process.

I do care, a lot. That's why I'm still here, and that's why I've created
pull requests to get our changes up stream. I want other people to be
able to benefit from our work, and I'd like (on a personal level) to be
able to continue contributing to the success of pg in the enterprise
markets.

I have had conversations with developers from other large FOSS projects
who would love to advocate more postgresql adoption but are hesitant to
do so based upon the 'stagnant' perception they have of the driver. Most
of their concerns focus on lacking implementations or issues with jdbc
4.x and blobs.

> Since "transition" is necessary so are the politics.

Bull.

What's bothering me is not politics. What's bothering me is the giant
vacuum of direction. There is no long-term goal. There's no plan to EOL
or sunset support for specific combinations of systems. There's no
structure or path for incorporating new ideas, new talent, or new
features into the project.

The defacto leader right now is Dave, and his calls for action have come
up empty handed so far. There's been calls to create a managing 'board'
(for lack of better words) to manage the political process, and so far,
no one has actually *done* anything. It's the lack of action, on all
accounts, which is truly bothering me.

The 'politics' as you put it are just window dressing. In reality none
of us need to sit here and put up with it. We just need one person
(anyone) who has the guts to say, "Let's go", draft a project charter,
fork the repo, and be done with this. The existing driver can sit here
and rot in 'maintenance' mode.

I think what everyone is waiting for is for Dave to say, Ok, let's do
this (and describe a plan). Instead, what we got was (heavily
paraphrased) 'I don't have time for this who wants to inherit the mess?'
I don't blame him, and I sure didn't volunteer. This is a consequence of
not having a managing board or road-map.

FOSS projects never really die. They just fade into irrelevance.

Regards,
-Bryan Varner