Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: domain of jta@bristowhill.com
 designates 66.75.162.134 as permitted sender)
Message-ID: <42A0B2D3.1050401@bristowhill.com>
Date: Fri, 03 Jun 2005 12:43:15 -0700
From: "Jean T. Anderson" <jta@bristowhill.com>
User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324)
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: [jira] Updated: (DERBY-257) Format Contributing to Derby, Tips
 and Tasks To Get You Started Document for the website
References: <794667866.1114975925856.JavaMail.jira@ajax.apache.org>
	 <1370669821.1117816408280.JavaMail.jira@ajax.apache.org>
 <d9619e4a0506031230812f4@mail.gmail.com>
In-Reply-To: <d9619e4a0506031230812f4@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

my update to DERBY-257 was to just remove the version info, per Andrew's 
earlier email:

> Jean:
> http://issues.apache.org/jira/browse/DERBY-43 - close
> http://issues.apache.org/jira/browse/DERBY-257 - move (to Unassigned  version) 

But I also saw that Jira notice come through and had trouble seeing what 
had changed. It didn't go from the version to "Unassigned" as I 
expected, but from the version to blank. This is one example when 
filling in an optional comment would have helped.

sorry for the confusion!

Actually, since lots of entries on Kathey's original entry could be 
updated, I'll try to do that soon.

thanks for the info,

  -jean


Mamta Satoor wrote:
> Hi Jean,
>  
> Looks like at least some of the items identified as tasks that are may 
> be good candidates for first changes
> have either been take care of or we have someone actively working on 
> them. I haven't gone through the
> entire list but following are some of them.
>  
> Derby-205
> Rename org.apache.derby.impl.drda.DB2jServerImpl to 
> NetworkServerControlImpl. A useful cleanup project to take you through 
> the change cycle.
> 
> Derby-243
> connection toString() doesn't give enough information
> 
> Derby-180
> XCL47 SQL State duplicated in messages_en.properties.  Go through the 
> code change process and learn about how Derby Handles SQLStates
> 
> DERBY-229
> Column names on ResultSet.updateXXX and getXXX methods are handled 
> incorrectly
> 
> thanks,
> Mamta
> 
> 
> 
>  
> On 6/3/05, *Jean T. Anderson (JIRA)* <derby-dev@db.apache.org 
> <mailto:derby-dev@db.apache.org>> wrote:
> 
>         [ http://issues.apache.org/jira/browse/DERBY-257?page=all
>     <http://issues.apache.org/jira/browse/DERBY-257?page=all> ]
> 
>     Jean T. Anderson updated DERBY-257:
>     -----------------------------------
> 
>        Fix Version:     (was: 10.1.0.0 <http://10.1.0.0>)
>        Description:
>     Format the document below for the website.
> 
> 
>     It will have to be a living document so things get removed as they are
>     fixed and new ones get added.   It would also be nice to have a
>     volunteer to keep it maintained and pester derby-dev from time to
>     get suggestions for new items for the list.
> 
>     If there is a good, "How to Get Started in Open Source Development"
>     article.
>     That might be nice to add too.
> 
> 
>     Whomever volunteers to do it can post the page to the Jira issue.
>     Options for formatting content for the web site are at
>     http://incubator.apache.org/derby/papers/index.html#How+to+Contribute+Papers
> 
>     This was filed 5/1/2005. Check listed bugs for current status
>     whenever this document gets formatted for the website.
>     --------------------------------------------------------
> 
>     Contributing to Derby, Tips and Tasks To Get You Started
> 
>     So you are new to Derby and want to contribute right
>     away.  Here  are some ideas to get you started.
> 
> 
>     Ongoing Projects
> 
>     Below are some ongoing projects, which are great starting places and
>     always available.
> 
>     Test the Documentation
> 
>     Pick a manual, review it carefully and test all the examples.  If
>     you find something that looks wrong post a question to
>     derby-user@apache.org <mailto:derby-user@apache.org>.  If the
>     community confirms it as a  documentation bug, file a Jira entry.
> 
> 
>     Answer User Questions
> 
>     Answer user questions as they come in to derby-user@apache.org
>     <mailto:derby-user@apache.org>. Make sure bugs get filed properly
>     when they come up. File bugs for documentation corrections and
>     update FAQ's.
> 
> 
>     Add Functional Tests
> 
>     Until we have 100% code coverage we know there are still
>     opportunities to enhance functional testing.   See
>     https://svn.apache.org/viewcvs.cgi/*checkout*/incubator/derby/code/trunk/java/testing/README.htm
>     for information on writing tests.  Write the tests and if you hit
>     something that doesn't work, post a question to
>     derby-user@apache.org <mailto:derby-user@apache.org> for
>     confirmation.   If the community confirms it as a  bug, file a Jira
>     entry.
> 
> 
>     Add More Existing Tests To the Network Server Suite.
> 
>     This is entered as Derby-209.   Choosing this as an initial task
>     will help you come up to speed on the test harness and network server.
> 
>     Add Stress and Scalability Tests
> 
>     Choose something that Derby does and push it to the limit. Some of
>     these kinds of tests can be incorporated into the functional test
>     framework. For example Derby 216 is a task to expand on the test
>     case for Derby-176 related to cases where large amounts of byte code
>     are generated.
> 
> 
>     Provide Benchmark / Performance Examples:
> 
>     Derby could use some contributions in the benchmark/performance
>     example area.  This is a good area for someone who wants to learn
>     any of java, jdbc, sql and/or derby.  It would be nice to have some
>     public examples applications/code which runs well in the derby
>     embedded server domain.
>     Extra credit:
>          o compare/contrast performance of same application with other dbs.
>          o implement public domain standard benchmark.
> 
> 
>     Write Tests for an Upcoming Feature
> 
>     You may ask how you can do this, but because Derby is standards
>     based, you can often install your second favorite relational
>     database software, one that has the feature already implemented and
>     run your tests against that.  Then you can post your test to the
>     Jira entry. This will facilitate implementation and improve quality.
> 
>     Apply, Test and Review  Patches
> 
>     Apply, review and test patches that have been posted for
>     review.  Really make a careful detailed review, try to understand
>     all the code and if you don't, ask questions about it.  Look at the
>     functional tests supplied and see if you can think of additional
>     cases that could be added.  This is a highly valuable task. If the
>     committers don't have community members doing this, they spend all
>     their time reviewing and committing and never contributing
>     themselves.  This task will  help preserve the quality of Derby.
> 
>     Cleanup and Expand Javadoc
> 
>     In addition to Derby-204, to cleanup the javadoc warnings.  Much of
>     the javadoc could be expanded and improved upon. package.html files
>     can be created to give a package overview.   Committers are always
>     happy to assist, review and expedite these kinds of contributions
>     because they enhance  the overall competency of the community.
> 
> 
>     First Code Changes
> 
>     For your first code change choose something that looks really easy.
>     Something you can do and do well. This will be something different
>     for different people. The point of your first change should be to go
>     through the whole process and be comfortable with it before taking
>     on major coding projects.
> 
>     A  "Do no harm" mantra is always important if you are considering
>     changing Derby. Your first priority in introducing any new
>     functionality should be to not introduce a regression in
>     functionality or performance.
> 
>     Reference Materials
> 
>     For general process and guidelines see:
>        http://db.apache.org/guidelines.html
>        http://www.apache.org/foundation/how-it-works.html
> 
>     For the mechanics of building Derby and submitting a patch see
>        http://incubator.apache.org/derby/derby_downloads.html
>     <http://incubator.apache.org/derby/derby_downloads.html>
>        http://incubator.apache.org/derby/derby_comm.html
> 
>     For Derby Internals
>        http://incubator.apache.org/derby/papers/index.html
>     <http://incubator.apache.org/derby/papers/index.html>
>        Read the javadoc.
> 
> 
>     Below are some tasks that are may be good candidates for first changes.
> 
>     Derby-204
>     Cleanup  Derby javadoc warnings.  Take a tour of the code and add
>     great value. Feel free to take a subset of the javadoc in an area
>     that interests you.
> 
>     Derby-209
>     Add more tests to Network Server.
>     Learn about Network Server, the test harness, and help improve
>     network server quality.
> 
> 
>     Derby-205
>     Rename org.apache.derby.impl.drda.DB2jServerImpl to
>     NetworkServerControlImpl. A useful cleanup project to take you
>     through the change cycle.
> 
>     Derby-243
>     connection toString() doesn't give enough information
> 
>     Derby-216
>     Derby-176 test case. Try to identify cases where Derby generates
>     byte code that exceeds the JVM Specification limits. This is an
>     interesting white box testing task that can be a good entry point if
>     you are interested in code generation or code paths for different
>     types of queries.
> 
> 
>     Derby-180
>     XCL47 SQL State duplicated in messages_en.properties.  Go through
>     the code change process and learn about how Derby Handles SQLStates
> 
> 
>     Derby-212
>     Optimize some specific methods in Network Server. A targeted place
>     to get started in Network Server and improve Network Server
>     performance.
> 
> 
>     Derby-211
>     Network Server returns no result sets for a procedure call that
>     returns no result. A protocol fix that will help us work toward
>     network server/ embedded compatibility
> 
>     Derby-51
> 
>     Need NetworkServerControl shutdown API method that does not shutdown
>     derby embedded.  This will allow applications that embed network
>     server to shut down the server and continue with embedded access.
> 
>     Derby-17
>     Network Server Needs to generate CRRTKN on ACCRDB if client does not
>     send it
> 
> 
>     Derby 104
>     Get rid of the Max length of 18 for constraint names.  Help Jira and
>     other applications migrate to Derby easily.
> 
>     Derby 223
>     Change programs under demo directory to use consistent package names
>     so IDEs do not report errors
> 
>     Derby-197
> 
>     Add tip for Windows users in BUILDING.txt file regarding file paths
>     in the ant.properties file. Save new folks a lot of time.
> 
>     Derby-117
> 
>     Try out patch for Derby 117 and verify changes. Good introduction to
>     the Network Server Servlet
> 
> 
>     Derby 213
>     ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL
>     Exception with Network Server
> 
> 
>     DERBY-229
>     Column names on ResultSet.updateXXX and getXXX methods are handled
>     incorrectly
> 
>     DERBY-203
>     setNull(x,JDBCType.DATE) does not work when batching is turned on
> 
>     DERBY-195
>     isSearchable() returns true for a calculated field
> 
>     DERBY-194
>     getPrecision() on TIME and TIMESTAMP is zero
> 
>     DERBY-163
>     Timestamp formatting
> 
>     DERBY-39
>     Strange error in JOIN ON clause
> 
> 
> 
>     Derby client Tasks
> 
>     There are some very time critical Derby client tasks that are fairly
>     large but  great starters in terms of difficulty. There is no
>     component for Derby client in Jira yet.  So they don't have JIRA
>     numbers.
> 
>     Match embedded SQL States wherever possible.
>     The client tends to throw errors with null SQLStates or SQLStates
>     that don't match embedded.  It would be great to get them matched up
>     before release.
> 
>     Document areas of embedded incompatibility and file  JIRA entries
>     In addition to the SQLStates, there may be additional
>     incompatibilities with the embedded driver. These could be indicated
>     in the documentation as areas that may change, so we don't get
>     locked into any incompatibilities.  This task could be done in
>     conjunction with Derby-209.
> 
> 
> 
> 
>     was:
>     Format the document below for the website.
> 
> 
>     It will have to be a living document so things get removed as they are
>     fixed and new ones get added.   It would also be nice to have a
>     volunteer to keep it maintained and pester derby-dev from time to
>     get suggestions for new items for the list.
> 
>     If there is a good, "How to Get Started in Open Source Development"
>     article.
>     That might be nice to add too.
> 
> 
>     Whomever volunteers to do it can post the page to the Jira issue.
>     Options for formatting content for the web site are at
>     http://incubator.apache.org/derby/papers/index.html#How+to+Contribute+Papers
> 
>     This was filed 5/1/2005. Check listed bugs for current status
>     whenever this document gets formatted for the website.
>     --------------------------------------------------------
> 
>     Contributing to Derby, Tips and Tasks To Get You Started
> 
>     So you are new to Derby and want to contribute right
>     away.  Here  are some ideas to get you started.
> 
> 
>     Ongoing Projects
> 
>     Below are some ongoing projects, which are great starting places and
>     always available.
> 
>     Test the Documentation
> 
>     Pick a manual, review it carefully and test all the examples.  If
>     you find something that looks wrong post a question to
>     derby-user@apache.org <mailto:derby-user@apache.org>.  If the
>     community confirms it as a  documentation bug, file a Jira entry.
> 
> 
>     Answer User Questions
> 
>     Answer user questions as they come in to derby-user@apache.org
>     <mailto:derby-user@apache.org>. Make sure bugs get filed properly
>     when they come up. File bugs for documentation corrections and
>     update FAQ's.
> 
> 
>     Add Functional Tests
> 
>     Until we have 100% code coverage we know there are still
>     opportunities to enhance functional testing.   See
>     https://svn.apache.org/viewcvs.cgi/*checkout*/incubator/derby/code/trunk/java/testing/README.htm
>     for information on writing tests.  Write the tests and if you hit
>     something that doesn't work, post a question to
>     derby-user@apache.org <mailto:derby-user@apache.org> for
>     confirmation.   If the community confirms it as a  bug, file a Jira
>     entry.
> 
> 
>     Add More Existing Tests To the Network Server Suite.
> 
>     This is entered as Derby-209.   Choosing this as an initial task
>     will help you come up to speed on the test harness and network server.
> 
>     Add Stress and Scalability Tests
> 
>     Choose something that Derby does and push it to the limit. Some of
>     these kinds of tests can be incorporated into the functional test
>     framework. For example Derby 216 is a task to expand on the test
>     case for Derby-176 related to cases where large amounts of byte code
>     are generated.
> 
> 
>     Provide Benchmark / Performance Examples:
> 
>     Derby could use some contributions in the benchmark/performance
>     example area.  This is a good area for someone who wants to learn
>     any of java, jdbc, sql and/or derby.  It would be nice to have some
>     public examples applications/code which runs well in the derby
>     embedded server domain.
>     Extra credit:
>          o compare/contrast performance of same application with other dbs.
>          o implement public domain standard benchmark.
> 
> 
>     Write Tests for an Upcoming Feature
> 
>     You may ask how you can do this, but because Derby is standards
>     based, you can often install your second favorite relational
>     database software, one that has the feature already implemented and
>     run your tests against that.  Then you can post your test to the
>     Jira entry. This will facilitate implementation and improve quality.
> 
>     Apply, Test and Review  Patches
> 
>     Apply, review and test patches that have been posted for
>     review.  Really make a careful detailed review, try to understand
>     all the code and if you don't, ask questions about it.  Look at the
>     functional tests supplied and see if you can think of additional
>     cases that could be added.  This is a highly valuable task. If the
>     committers don't have community members doing this, they spend all
>     their time reviewing and committing and never contributing
>     themselves.  This task will  help preserve the quality of Derby.
> 
>     Cleanup and Expand Javadoc
> 
>     In addition to Derby-204, to cleanup the javadoc warnings.  Much of
>     the javadoc could be expanded and improved upon. package.html files
>     can be created to give a package overview.   Committers are always
>     happy to assist, review and expedite these kinds of contributions
>     because they enhance  the overall competency of the community.
> 
> 
>     First Code Changes
> 
>     For your first code change choose something that looks really easy.
>     Something you can do and do well. This will be something different
>     for different people. The point of your first change should be to go
>     through the whole process and be comfortable with it before taking
>     on major coding projects.
> 
>     A  "Do no harm" mantra is always important if you are considering
>     changing Derby. Your first priority in introducing any new
>     functionality should be to not introduce a regression in
>     functionality or performance.
> 
>     Reference Materials
> 
>     For general process and guidelines see:
>        http://db.apache.org/guidelines.html
>        http://www.apache.org/foundation/how-it-works.html
> 
>     For the mechanics of building Derby and submitting a patch see
>        http://incubator.apache.org/derby/derby_downloads.html
>     <http://incubator.apache.org/derby/derby_downloads.html>
>        http://incubator.apache.org/derby/derby_comm.html
> 
>     For Derby Internals
>        http://incubator.apache.org/derby/papers/index.html
>     <http://incubator.apache.org/derby/papers/index.html>
>        Read the javadoc.
> 
> 
>     Below are some tasks that are may be good candidates for first changes.
> 
>     Derby-204
>     Cleanup  Derby javadoc warnings.  Take a tour of the code and add
>     great value. Feel free to take a subset of the javadoc in an area
>     that interests you.
> 
>     Derby-209
>     Add more tests to Network Server.
>     Learn about Network Server, the test harness, and help improve
>     network server quality.
> 
> 
>     Derby-205
>     Rename org.apache.derby.impl.drda.DB2jServerImpl to
>     NetworkServerControlImpl. A useful cleanup project to take you
>     through the change cycle.
> 
>     Derby-243
>     connection toString() doesn't give enough information
> 
>     Derby-216
>     Derby-176 test case. Try to identify cases where Derby generates
>     byte code that exceeds the JVM Specification limits. This is an
>     interesting white box testing task that can be a good entry point if
>     you are interested in code generation or code paths for different
>     types of queries.
> 
> 
>     Derby-180
>     XCL47 SQL State duplicated in messages_en.properties.  Go through
>     the code change process and learn about how Derby Handles SQLStates
> 
> 
>     Derby-212
>     Optimize some specific methods in Network Server. A targeted place
>     to get started in Network Server and improve Network Server
>     performance.
> 
> 
>     Derby-211
>     Network Server returns no result sets for a procedure call that
>     returns no result. A protocol fix that will help us work toward
>     network server/ embedded compatibility
> 
>     Derby-51
> 
>     Need NetworkServerControl shutdown API method that does not shutdown
>     derby embedded.  This will allow applications that embed network
>     server to shut down the server and continue with embedded access.
> 
>     Derby-17
>     Network Server Needs to generate CRRTKN on ACCRDB if client does not
>     send it
> 
> 
>     Derby 104
>     Get rid of the Max length of 18 for constraint names.  Help Jira and
>     other applications migrate to Derby easily.
> 
>     Derby 223
>     Change programs under demo directory to use consistent package names
>     so IDEs do not report errors
> 
>     Derby-197
> 
>     Add tip for Windows users in BUILDING.txt file regarding file paths
>     in the ant.properties file. Save new folks a lot of time.
> 
>     Derby-117
> 
>     Try out patch for Derby 117 and verify changes. Good introduction to
>     the Network Server Servlet
> 
> 
>     Derby 213
>     ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL
>     Exception with Network Server
> 
> 
>     DERBY-229
>     Column names on ResultSet.updateXXX and getXXX methods are handled
>     incorrectly
> 
>     DERBY-203
>     setNull(x,JDBCType.DATE) does not work when batching is turned on
> 
>     DERBY-195
>     isSearchable() returns true for a calculated field
> 
>     DERBY-194
>     getPrecision() on TIME and TIMESTAMP is zero
> 
>     DERBY-163
>     Timestamp formatting
> 
>     DERBY-39
>     Strange error in JOIN ON clause
> 
> 
> 
>     Derby client Tasks
> 
>     There are some very time critical Derby client tasks that are fairly
>     large but  great starters in terms of difficulty. There is no
>     component for Derby client in Jira yet.  So they don't have JIRA
>     numbers.
> 
>     Match embedded SQL States wherever possible.
>     The client tends to throw errors with null SQLStates or SQLStates
>     that don't match embedded.  It would be great to get them matched up
>     before release.
> 
>     Document areas of embedded incompatibility and file  JIRA entries
>     In addition to the SQLStates, there may be additional
>     incompatibilities with the embedded driver. These could be indicated
>     in the documentation as areas that may change, so we don't get
>     locked into any incompatibilities.  This task could be done in
>     conjunction with Derby-209.
> 
> 
> 
> 
>            Version:     (was: 10.1.0.0 <http://10.1.0.0>)
>        Environment:
> 
>      > Format Contributing to Derby, Tips and Tasks To Get You Started
>     Document for the website
>      >
>     ----------------------------------------------------------------------------------------
> 
>      >
>      >          Key: DERBY-257
>      >          URL: http://issues.apache.org/jira/browse/DERBY-257
>      >      Project: Derby
>      >         Type: Task
>      >   Components: Web Site
>      >     Reporter: Kathey Marsden
>      >     Priority: Trivial
> 
>      >
>      > Format the document below for the website.
>      > It will have to be a living document so things get removed as
>     they are
>      > fixed and new ones get added.   It would also be nice to have a
>     volunteer to keep it maintained and pester derby-dev from time to
>     get suggestions for new items for the list.
>      > If there is a good, "How to Get Started in Open Source
>     Development" article.
>      > That might be nice to add too.
>      > Whomever volunteers to do it can post the page to the Jira issue.
>     Options for formatting content for the web site are at
>     http://incubator.apache.org/derby/papers/index.html#How+to+Contribute+Papers
>      > This was filed 5/1/2005. Check listed bugs for current status
>     whenever this document gets formatted for the website.
>      > --------------------------------------------------------
>      > Contributing to Derby, Tips and Tasks To Get You Started
>      > So you are new to Derby and want to contribute right
>     away.  Here  are some ideas to get you started.
>      > Ongoing Projects
>      > Below are some ongoing projects, which are great starting places
>     and always available.
>      > Test the Documentation
>      >
>      > Pick a manual, review it carefully and test all the examples.  If
>     you find something that looks wrong post a question to
>     derby-user@apache.org <mailto:derby-user@apache.org>.  If the
>     community confirms it as a  documentation bug, file a Jira entry.
>      > Answer User Questions
>      > Answer user questions as they come in to derby-user@apache.org
>     <mailto:derby-user@apache.org> . Make sure bugs get filed properly
>     when they come up. File bugs for documentation corrections and
>     update FAQ's.
>      > Add Functional Tests
>      > Until we have 100% code coverage we know there are still
>     opportunities to enhance functional testing.   See
>     https://svn.apache.org/viewcvs.cgi/*checkout*/incubator/derby/code/trunk/java/testing/README.htm
>     for information on writing tests.  Write the tests and if you hit
>     something that doesn't work, post a question to
>     derby-user@apache.org <mailto:derby-user@apache.org> for
>     confirmation.   If the community confirms it as a  bug, file a Jira
>     entry.
>      > Add More Existing Tests To the Network Server Suite.
>      > This is entered as Derby-209.   Choosing this as an initial task
>     will help you come up to speed on the test harness and network server.
>      > Add Stress and Scalability Tests
>      > Choose something that Derby does and push it to the limit. Some
>     of these kinds of tests can be incorporated into the functional test
>     framework. For example Derby 216 is a task to expand on the test
>     case for Derby-176 related to cases where large amounts of byte code
>     are generated.
>      > Provide Benchmark / Performance Examples:
>      > Derby could use some contributions in the benchmark/performance
>     example area.  This is a good area for someone who wants to learn
>     any of java, jdbc, sql and/or derby.  It would be nice to have some
>     public examples applications/code which runs well in the derby
>     embedded server domain.
>      > Extra credit:
>      >       o compare/contrast performance of same application with
>     other dbs.
>      >       o implement public domain standard benchmark.
>      > Write Tests for an Upcoming Feature
>      > You may ask how you can do this, but because Derby is standards
>     based, you can often install your second favorite relational
>     database software, one that has the feature already implemented and
>     run your tests against that.  Then you can post your test to the
>     Jira entry. This will facilitate implementation and improve quality.
>      > Apply, Test and Review  Patches
>      > Apply, review and test patches that have been posted for
>     review.  Really make a careful detailed review, try to understand
>     all the code and if you don't, ask questions about it.  Look at the
>     functional tests supplied and see if you can think of additional
>     cases that could be added.  This is a highly valuable task. If the
>     committers don't have community members doing this, they spend all
>     their time reviewing and committing and never contributing
>     themselves.  This task will  help preserve the quality of Derby.
>      > Cleanup and Expand Javadoc
>      > In addition to Derby-204, to cleanup the javadoc warnings.  Much
>     of the javadoc could be expanded and improved upon. package.html
>     files can be created to give a package overview.   Committers are
>     always happy to assist, review and expedite these kinds of
>     contributions because they enhance  the overall competency of the
>     community.
>      > First Code Changes
>      > For your first code change choose something that looks really
>     easy. Something you can do and do well. This will be something
>     different for different people. The point of your first change
>     should be to go through the whole process and be comfortable with it
>     before taking on major coding projects.
>      > A  "Do no harm" mantra is always important if you are considering
>     changing Derby. Your first priority in introducing any new
>     functionality should be to not introduce a regression in
>     functionality or performance.
>      > Reference Materials
>      > For general process and guidelines see:
>      >     http://db.apache.org/guidelines.html
>      >     http://www.apache.org/foundation/how-it-works.html
>      >
>      > For the mechanics of building Derby and submitting a patch see
>      >     http://incubator.apache.org/derby/derby_downloads.html
>     <http://incubator.apache.org/derby/derby_downloads.html>
>      >     http://incubator.apache.org/derby/derby_comm.html
>      > For Derby Internals
>      >     http://incubator.apache.org/derby/papers/index.html
>      >     Read the javadoc.
>      > Below are some tasks that are may be good candidates for first
>     changes.
>      > Derby-204
>      > Cleanup  Derby javadoc warnings.  Take a tour of the code and add
>     great value. Feel free to take a subset of the javadoc in an area
>     that interests you.
>      > Derby-209
>      > Add more tests to Network Server.
>      > Learn about Network Server, the test harness, and help improve
>     network server quality.
>      > Derby-205
>      > Rename org.apache.derby.impl.drda.DB2jServerImpl to
>     NetworkServerControlImpl. A useful cleanup project to take you
>     through the change cycle.
>      > Derby-243
>      > connection toString() doesn't give enough information
>      > Derby-216
>      > Derby-176 test case. Try to identify cases where Derby generates
>     byte code that exceeds the JVM Specification limits. This is an
>     interesting white box testing task that can be a good entry point if
>     you are interested in code generation or code paths for different
>     types of queries.
>      >
>      > Derby-180
>      > XCL47 SQL State duplicated in messages_en.properties.  Go through
>     the code change process and learn about how Derby Handles SQLStates
>      > Derby-212
>      > Optimize some specific methods in Network Server. A targeted
>     place to get started in Network Server and improve Network Server
>     performance.
>      > Derby-211
>      > Network Server returns no result sets for a procedure call that
>     returns no result. A protocol fix that will help us work toward
>     network server/ embedded compatibility
>      > Derby-51
>      > Need NetworkServerControl shutdown API method that does not
>     shutdown derby embedded.  This will allow applications that embed
>     network server to shut down the server and continue with embedded
>     access.
>      > Derby-17
>      > Network Server Needs to generate CRRTKN on ACCRDB if client does
>     not send it
>      > Derby 104
>      > Get rid of the Max length of 18 for constraint names.  Help Jira
>     and other applications migrate to Derby easily.
>      > Derby 223
>      > Change programs under demo directory to use consistent package
>     names so IDEs do not report errors
>      > Derby-197
>      > Add tip for Windows users in BUILDING.txt file regarding file
>     paths in the ant.properties file. Save new folks a lot of time.
>      > Derby-117
>      > Try out patch for Derby 117 and verify changes. Good introduction
>     to the Network Server Servlet
>      > Derby 213
>      > ResultSet.next() after last row of FORWARD_ONLY cursor throws an
>     SQL Exception with Network Server
>      > DERBY-229
>      > Column names on ResultSet.updateXXX and getXXX methods are
>     handled incorrectly
>      > DERBY-203
>      > setNull(x,JDBCType.DATE) does not work when batching is turned on
>      > DERBY-195
>      > isSearchable() returns true for a calculated field
>      > DERBY-194
>      > getPrecision() on TIME and TIMESTAMP is zero
>      > DERBY-163
>      > Timestamp formatting
>      > DERBY-39
>      > Strange error in JOIN ON clause
>      > Derby client Tasks
>      > There are some very time critical Derby client tasks that are
>     fairly large but  great starters in terms of difficulty. There is no
>     component for Derby client in Jira yet.  So they don't have JIRA
>     numbers.
>      > Match embedded SQL States wherever possible.
>      > The client tends to throw errors with null SQLStates or SQLStates
>     that don't match embedded.  It would be great to get them matched up
>     before release.
>      > Document areas of embedded incompatibility and file  JIRA entries
>      > In addition to the SQLStates, there may be additional
>     incompatibilities with the embedded driver. These could be indicated
>     in the documentation as areas that may change, so we don't get
>     locked into any incompatibilities.  This task could be done in
>     conjunction with Derby-209.
> 
>     --
>     This message is automatically generated by JIRA.
>     -
>     If you think it was sent incorrectly contact one of the administrators:
>       http://issues.apache.org/jira/secure/Administrators.jspa
>     <http://issues.apache.org/jira/secure/Administrators.jspa>
>     -
>     For more information on JIRA, see:
>       http://www.atlassian.com/software/jira
> 
>