Pgsql_JDBC Support Proposal

From: dmp <danap(at)ttc-cmc(dot)net>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Pgsql_JDBC Support Proposal
Date: 2012-08-23 19:21:21
Message-ID: 503682B1.7020900@ttc-cmc.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

> New thread derived from:
> Re: [JDBC] setObject(...) with native Java arrays like String[] ?

The discussion I open here is possibly an outlandish proposal
for the PgJDBC support requirements for the project, but is
really meant to enlist a basic discussion of a solution in this
area for the project's needs. I do not know the size of this
mailing list, but suspect it is fairly large, since PostgreSQL
has been gaining popularity in the last few years. I would
therefore assume that this is NOT a dying project. I for one
do not wish to see it flounder, since I think PostgreSQL with
the JDBC provides an alternative that is reasonable for
individuals and businesses alike.

Now, since I have managed a small project for several years &
done some professional project management I realize that time
and manpower are the keys. Even a SMALL project when broken down
into it basic requirements, promotion, aka marketing, development,
patches, documentation, releases, and support can be quite time
consuming for even several individuals. Since open source projects
pay no monetary compensation contributions to a project's needs to
be based on personal motivation that brings benefits. In the case
here that is going to vary for each individual & of course each
having time limitations. Though rather winded I think this brings
some parameters to the basis for what I suggest below and my
interest in one possible outlandish solution.

1. Keep it very simple, easy for newbies to understand & partake.

2. Therefore from 1. group all the project's needs into a few categories.
A. Promotion, evangelist.
*B. Development, patches, documentation.
*C. Release.
D. Support.

As highlighted only B. & C. I think are the issues at this time
that are wanting for a solution. A. is going to happen or not,
if it doesn't through self promotion then the project is dead.
D. already has a solution through the mailing list.

3. Again from 1. make all requirements for 2.B. come under one
solution.

4. Again from 1. automate C., which is seems to be already done?
except possibly website changes.

5. Put 2.B. with D., through the mailing list therefore promoting
again 1.

Proposal: Enlist the mailing list to have already vested users to
review patches in the form of development & documentation
patches. Have new patches, summary, posted to mailing list.
Ask one registered user of mailing list to monitor & review
patches and then comment. Limit each requested mailing list
reviewer to say one week, whereas the next reviewer will
take over. Ask the reviewer to post comment on say plus,
minus, neutral, or checklist outcome from 5. below. Require
patch to achieve three pluses to make into commit. Somehow
through the mailing list allow the submitter of the patch
to prod the current selected reviewer, to promote their
patch to get it through, answer questions directly. Have
current posted patches & their status posted to the mailing
list at the beginning of each reviewers period.

Assumption: The mailing list is large enough & there is a modest
percentage of users with a vested motivation to continue
with the benefits of the project. Any solution is not
going to happen overnight, but may take months if not
six months or more.

Requirements:

1. Notification, enlistment through mailing list, acceptance.
2. How to make it really easy if a user does not have development
environment setup to review patches.
3. Status/update of patches to mailing list.
4. Set up guidelines of what is required to submitt a patch, test
case, documentation, formatting, possible performance hits.
5. Instructions for reviewers in processing patches. Simple checklist?

Contribution: I would be willing to contribute to creating the automated
solutions to make this work in either 1. 2. or/& 3. in
the requirements. Perhaps there is already a solution out
there for this so I could also contribute in researching.

Though this may not be an acceptable proposal for the project I would
still be be willing to make the type of contributions indicated if an
agreed upon solution achieves a good level of automation for the process.
I would not be willing to contrinbute to other proposals unless I'm
convinced of the automation, workability, success factor, and its time
factor is not a black hole for me.

Dana M. Proctor
MyJSQLView Project Manager
http://dandymadeproductions.com

Browse pgsql-jdbc by date

  From Date Subject
Next Message Craig Ringer 2012-08-24 02:23:05 Re: setObject(...) with native Java arrays like String[] ?
Previous Message Dave Cramer 2012-08-23 18:16:08 Re: setObject(...) with native Java arrays like String[] ?