Pgsql_JDBC Support Proposal

 > 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