You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by co...@apache.org on 2005/01/19 13:05:56 UTC
svn commit: r125617 - /incubator/derby/code/trunk/STATUS
Author: coar
Date: Wed Jan 19 04:05:56 2005
New Revision: 125617
URL: http://svn.apache.org/viewcvs?view=rev&rev=125617
Log:
Reformat for better wrapping
Modified:
incubator/derby/code/trunk/STATUS
Modified: incubator/derby/code/trunk/STATUS
Url: http://svn.apache.org/viewcvs/incubator/derby/code/trunk/STATUS?view=diff&rev=125617&p1=incubator/derby/code/trunk/STATUS&r1=125616&p2=incubator/derby/code/trunk/STATUS&r2=125617
==============================================================================
--- incubator/derby/code/trunk/STATUS (original)
+++ incubator/derby/code/trunk/STATUS Wed Jan 19 04:05:56 2005
@@ -8,30 +8,33 @@
Description
- "Derby" is a snapshot of the IBM's Cloudscape Java relational database. IBM is
- opening the code by contributing it to The Apache Software Foundation and
- basing future versions of IBM Cloudscape on the Apache-managed code.
-
- To participate in the Derby podling, you should join the mailing list. Just
- send an empty message to derby-dev-subscribe@db.apache.org .
-
- The initial goal of the project while in incubation is to build a viable
- developer community around the codebase.
-
- The second goal of Derby-in-incubation is to successfully produce a release.
- Since Derby is in incubation, such a release would not have formal standing;
- it will serve as a proof-of-concept to demonstrate to the developers' and
- incubator's satisfaction that this aspect of the project is health and
- understood.
+ "Derby" is a snapshot of the IBM's Cloudscape Java relational
+ database. IBM is opening the code by contributing it to The Apache
+ Software Foundation and basing future versions of IBM Cloudscape on
+ the Apache-managed code.
+
+ To participate in the Derby podling, you should join the mailing
+ list. Just send an empty message to derby-dev-subscribe@db.apache.org .
+
+ The initial goal of the project while in incubation is to build a
+ viable developer community around the codebase.
+
+ The second goal of Derby-in-incubation is to successfully produce a
+ release. Since Derby is in incubation, such a release would not
+ have formal standing; it will serve as a proof-of-concept to
+ demonstrate to the developers' and incubator's satisfaction that
+ this aspect of the project is health and understood.
Project info
- * The Apache DB project will own the Derby subproject, and the subproject will
- follow the Apache DB PMC's direction. Significant contributors to this sub-
- project (for example, after a significant interval of sustained contribution)
- will be proposed for commit access to the codebase.
+ * The Apache DB project will own the Derby subproject, and the
+ subproject will follow the Apache DB PMC's direction. Significant
+ contributors to this sub- project (for example, after a
+ significant interval of sustained contribution) will be proposed
+ for commit access to the codebase.
- * The Derby sub-project's modules will be available as distinct and discrete downloads.
+ * The Derby sub-project's modules will be available as distinct and
+ discrete downloads.
Detailed References:
@@ -62,34 +65,43 @@
Identify the codebase
date item
-2004-08-30 If applicable, make sure that any associated name does not already
- exist and check www.nameprotect.com to be sure that the name is not
- already trademarked for an existing software product.
+2004-08-30 If applicable, make sure that any associated name does not
+ already exist and check www.nameprotect.com to be sure
+ that the name is not already trademarked for an existing
+ software product.
Copyright
date item
-2004-08-26 Check and make sure that the papers that transfer rights to the ASF
- been received. It is only necessary to transfer rights for the
- package, the core code, and any new code produced by the project.
-2004-11-04 Check and make sure that the files that have been donated have been
- updated to reflect the new ASF copyright.
+2004-08-26 Check and make sure that the papers that transfer rights to
+ the ASF been received. It is only necessary to transfer
+ rights for the package, the core code, and any new code
+ produced by the project.
+2004-11-04 Check and make sure that the files that have been donated
+ have been updated to reflect the new ASF copyright.
Verify distribution rights
date item
-2004-10-12 Check that all active committers have a signed CLA on record.
-2004-10-12 Remind active committers that they are responsible for ensuring that
- a Corporate CLA is recorded if such is is required to authorize
- their contributions under their individual CLA.
-2004-10-12 Check and make sure that for all items included with the distribution
- that is not under the Apache license, we have the right to combine
- with Apache-licensed code and redistribute.
-2004-10-12 Check and make sure that all items depended upon by the project is
- covered by one or more of the following approved licenses: Apache,
- BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially
- the same terms.
+2004-10-12 Check that all active committers have a signed CLA on
+ record.
+2004-10-12 Remind active committers that they are responsible for
+ ensuring that a Corporate CLA is recorded if such is is
+ required to authorize their contributions under their
+ individual CLA.
+2004-10-12 Check and make sure that for all items included with the
+ distribution that is not under the Apache license, we have
+ the right to combine with Apache-licensed code and
+ redistribute.
+2004-10-12 Check and make sure that all items depended upon by the
+ project is covered by one or more of the following
+ approved licenses: Apache, BSD, Artistic, MIT/X, MIT/W3C,
+ MPL 1.1, or something with essentially the same terms.
+
+Generally, the result of checking off these items will be a Software
+Grant, CLA, and Corporate CLA for ASF licensed code, which must have
+no dependencies upon items whose licenses that are incompatible with
+the Apache License.
-Generally, the result of checking off these items will be a Software Grant, CLA, and Corporate CLA for ASF licensed code, which must have no dependencies upon items whose licenses that are incompatible with the Apache License.
Organizational acceptance of responsibility for the project
* Has the receiving PMC voted to accept it? **YES**
@@ -106,37 +118,40 @@
Derby documentation in PDF format:
- A request was made for PDF documentation, however, the source files for the
- current HTML documentation for Derby are not in a form useful for creating PDF
- documentation with Forrest. A proposal was made by Jeff Levitt
- <jl...@mutagen.net> to convert the documentation into XML DITA format.
-
- The Getting Started and Reference Manual were converted to DITA and are
- available for review from http://incubator.apache.org/derby/manuals/index.html
+ A request was made for PDF documentation, however, the source files
+ for the current HTML documentation for Derby are not in a form
+ useful for creating PDF documentation with Forrest. A proposal was
+ made by Jeff Levitt <jl...@mutagen.net> to convert the
+ documentation into XML DITA format.
+
+ The Getting Started and Reference Manual were converted to DITA and
+ are available for review from
+ http://incubator.apache.org/derby/manuals/index.html
RESOLVED ISSUES SINCE LAST STATUS
=================================
[VOTE] on repository layout:
- [ Ten votes ] Option 1: Keep the code and site pages in separately-versionable
- trees ( derby/site/{trunk,tags,branches}/<pages> and
+ [ Ten votes ] Option 1: Keep the code and site pages in
+ separately-versionable trees (
+ derby/site/{trunk,tags,branches}/<pages> and
derby/code/{t,t,b}<code> )
- [ One vote ] Option 2: Put all things Derby into a single tree
+ [ One vote ] Option 2: Put all things Derby into a single tree
( derby/{trunk,tags,branches}/{<code>,<pages>} )
[VOTE] Establish development model based on Apache DB guidelines
- Derby is being sponsored by the Apache DB project and the Derby status
- page states 'The Apache DB project will own the Derby subproject, and
- the subproject will follow the Apache DB PMC's direction'.
- (http://incubator.apache.org/projects/derby.html)
-
- A vote was proposed that the Derby development model
- follows the guidelines defined by the Apache DB project. This will set
- the initial rules for development, changes to the model could
+ Derby is being sponsored by the Apache DB project and the Derby
+ status page states 'The Apache DB project will own the Derby
+ subproject, and the subproject will follow the Apache DB PMC's
+ direction'. (http://incubator.apache.org/projects/derby.html)
+
+ A vote was proposed that the Derby development model follows the
+ guidelines defined by the Apache DB project. This will set the
+ initial rules for development, changes to the model could
subsequently be called for and voted on using the Derby developer
mailing list.
@@ -145,7 +160,8 @@
There is one difference that the Derby code is in SVN and not CVS.
Note the decision making page at http://db.apache.org/decisions.html
- and the Changes section on this page http://db.apache.org/source.html.
+ and the Changes section on this page
+ http://db.apache.org/source.html.
The Changes section indicates the commit model is:
@@ -156,10 +172,10 @@
degree of confidence in the change.
Doubtful changes, new features, and large scale overhauls need to be
- discussed before committing them into the repository. Any change that
- affects the semantics of an existing API function, the size of the
- program, configuration data formats, or other major areas must receive
- consensus approval before being committed.
+ discussed before committing them into the repository. Any change
+ that affects the semantics of an existing API function, the size of
+ the program, configuration data formats, or other major areas must
+ receive consensus approval before being committed.
(end-quote)
@@ -168,19 +184,20 @@
[VOTE] Derby upgrade policy
- A vote was proposed to accept that for any release of Derby the upgrade policy described in:
+ A vote was proposed to accept that for any release of Derby the
+ upgrade policy described in:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=derby-dev@db.apache.org&msgNo=77
is followed.
The summary is that any release of Derby can run against a database
- created by a previous release with either no upgrade, soft upgrade or
- hard upgrade mode, depending on the circumstance.
+ created by a previous release with either no upgrade, soft upgrade
+ or hard upgrade mode, depending on the circumstance.
- This would mean that if some new feature was added to Derby, before a
- release occurred the correct upgrade code would have to be written, if
- the feature contributor did not provide it.
+ This would mean that if some new feature was added to Derby, before
+ a release occurred the correct upgrade code would have to be
+ written, if the feature contributor did not provide it.
Result: Three +1 votes.
@@ -191,87 +208,89 @@
That the version scheme currently in place, and described in:
- http://nagoya.apache.org/eyebrowse/ReadMsg?listName=derby-
- dev@db.apache.org&msgNo=73
+ http://nagoya.apache.org/eyebrowse/ReadMsg?listName=derby-dev@db.apache.org&msgNo=73
- be accepted in order to facilitate the upgrade policy voted on and
- accepted in the Derby upgrade policy thread. As such, Derby versions
- should take the following form: MAJOR.Minor.interim.point {beta} (build
- identifier). As an example, the currently posted snapshot version of
- Derby is 10.0.2.0 (46005).
+ be accepted in order to facilitate the upgrade policy voted on and
+ accepted in the Derby upgrade policy thread. As such, Derby versions
+ should take the following form: MAJOR.Minor.interim.point {beta}
+ (build identifier). As an example, the currently posted snapshot
+ version of Derby is 10.0.2.0 (46005).
Whereby:
- Differences in the major version are used to identify large changes in
- architecture and functionality, and for which upgrade is required.
- Differences in the minor version are used to identify changes in
- functionality large enough to require an upgrade procedure for
- databases from the previous version, and for which upgrade is required.
- Differences in the interim version are used to identify significant
- differences in behavior of the database engine from the previous
- interim version, but for which upgrade to databases is not required.
- Differences in the point version are used to identify that any amount
- of change to the database engine has occurred from the previously
- released point version.
- That the build identifier be used to distinguish the exact state of the
- code from which any specific set of binaries have been compiled,
- That the beta flag in the version denote that the upgrade policy is in
- an indeterminate state with respect to the previous version and, as
- such, that an upgrade to a beta version of Derby is allowed, but an
- upgrade from a beta version of Derby to any other version of Derby is
- not allowed.
-
- I would like to further propose that, following that version scheme,
- that releases from any branch have a specific version number and be
- tagged in the repository. Thus, following this version scheme, the
- forthcoming baseline release of Derby should be versioned 10.0.2.1, as
- it includes changes which are not included in the first public version
- of the source. Once the release is ready, the version on the trunk will
- be changed to 10.0.2.1 and then tagged in subversion.
-
- I would like to also further propose that before changes which would
- require upgrade are allowed into the trunk, that the trunk be branched,
- so that the branch can serve as the reference for the upgrade policy.
- After branching, the minor (and/or major) version of the trunk will be
- incremented, and the beta tag applied to indicate that significant
- changes exist in the trunk which would require database upgrade and
- that the code for performing the upgrade has not been rigorously
- tested. As an example, before a change could be applied which would
- require upgrade, a new 10.0 branch would be created and the trunk would
- be reversioned 10.1.0.0 beta, in order to distinguish the trunk from
- the new branch and to allow changes that require a database upgrade
- into the trunk.
+ Differences in the major version are used to identify large changes
+ in architecture and functionality, and for which upgrade is
+ required. Differences in the minor version are used to identify
+ changes in functionality large enough to require an upgrade
+ procedure for databases from the previous version, and for which
+ upgrade is required. Differences in the interim version are used to
+ identify significant differences in behavior of the database engine
+ from the previous interim version, but for which upgrade to
+ databases is not required. Differences in the point version are
+ used to identify that any amount of change to the database engine
+ has occurred from the previously released point version.
+
+ That the build identifier be used to distinguish the exact state of
+ the code from which any specific set of binaries have been compiled,
+ That the beta flag in the version denote that the upgrade policy is
+ in an indeterminate state with respect to the previous version and,
+ as such, that an upgrade to a beta version of Derby is allowed, but
+ an upgrade from a beta version of Derby to any other version of
+ Derby is not allowed.
+
+ I would like to further propose that, following that version scheme,
+ that releases from any branch have a specific version number and be
+ tagged in the repository. Thus, following this version scheme, the
+ forthcoming baseline release of Derby should be versioned 10.0.2.1,
+ as it includes changes which are not included in the first public
+ version of the source. Once the release is ready, the version on the
+ trunk will be changed to 10.0.2.1 and then tagged in subversion.
+
+ I would like to also further propose that before changes which would
+ require upgrade are allowed into the trunk, that the trunk be
+ branched, so that the branch can serve as the reference for the
+ upgrade policy. After branching, the minor (and/or major) version
+ of the trunk will be incremented, and the beta tag applied to
+ indicate that significant changes exist in the trunk which would
+ require database upgrade and that the code for performing the
+ upgrade has not been rigorously tested. As an example, before a
+ change could be applied which would require upgrade, a new 10.0
+ branch would be created and the trunk would be reversioned 10.1.0.0
+ beta, in order to distinguish the trunk from the new branch and to
+ allow changes that require a database upgrade into the trunk.
Result: Three +1 votes. Passed.
[VOTE] Re: Help detecting client disconnects for network server
- Kathey Marsden proposed the following vote concerning the use of TCP keepalive
- for Network Server:
+ Kathey Marsden proposed the following vote concerning the use of TCP
+ keepalive for Network Server:
- 1) Have keepAlive on by default. It seems important not only for locks
- but for potential network server bloat due to connections not getting
- cleaned up. Result: Three +1 votes. Passed.
-
- 2) Add a property derby.drda.keepAlive={true|false} (defaults to true as
- described above). There seems to be a need to be able to turn keepAlive
- off in some cases. Result: Two +1 votes, no objections. Passed.
-
- 3) Add property derby.drda.connSoTimeout=<milliseconds> (defaults to 0,
- infinite) to provide the ability to have connections timeout after a
- period of inactivity. The connections will still timeout, even if the
- connection is working fine but will timeout after blocking on a read for
- this length of time. I am about +.5 on this one. It would be nice to
- provide the capability, but hesitate to add yet another property.
- Result: One +1 vote, objections noted. Not passed.
+ 1) Have keepAlive on by default. It seems important not only for
+ locks but for potential network server bloat due to connections not
+ getting cleaned up. Result: Three +1 votes. Passed.
+
+ 2) Add a property derby.drda.keepAlive={true|false} (defaults to
+ true as described above). There seems to be a need to be able to
+ turn keepAlive off in some cases. Result: Two +1 votes, no
+ objections. Passed.
+
+ 3) Add property derby.drda.connSoTimeout=<milliseconds> (defaults to
+ 0, infinite) to provide the ability to have connections timeout
+ after a period of inactivity. The connections will still timeout,
+ even if the connection is working fine but will timeout after
+ blocking on a read for this length of time. I am about +.5 on this
+ one. It would be nice to provide the capability, but hesitate to
+ add yet another property. Result: One +1 vote, objections
+ noted. Not passed.
Copyright issues with the Derby codebase
- There were concerns over how the IBM copyright notices attached to the
- Derby source files were to be retained, if at all. For the discussion
- of the concerns surrounding this issue, please see:
+ There were concerns over how the IBM copyright notices attached to
+ the Derby source files were to be retained, if at all. For the
+ discussion of the concerns surrounding this issue, please see:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=derby-dev@db.apache.org&msgId=1885981
@@ -283,16 +302,18 @@
OTHER NEWS
==========
-Bug tracking has been set up at http://issues.apache.org/jira/browse/DERBY
+ Bug tracking has been set up at http://issues.apache.org/jira/browse/DERBY
RELEASE STATUS
==============
-The first release, versioned 10.0.2.1, was announced on December 8, 2005.
+The first release, versioned 10.0.2.1, was announced on December 8,
+2005.
-Any release must be approved by the Incubator PMC and must clearly be marked as
-an incubator release, according to the Apache Incubator guidelines:
+Any release must be approved by the Incubator PMC and must clearly be
+marked as an incubator release, according to the Apache Incubator
+guidelines:
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases%0A
@@ -302,47 +323,50 @@
Resolved showstoppers:
- DERBY-24 Client should not be able to raise an event on a PooledConnection
- it no longer owns.
+ DERBY-24 Client should not be able to raise an event on a
+ PooledConnection it no longer owns.
- DERBY-32 Logic to prevent mutiple jvms booting the same database in parallel
- to avoid accidental corruptions on Unix environment is not working.
+ DERBY-32 Logic to prevent mutiple jvms booting the same database in
+ parallel to avoid accidental corruptions on Unix environment is not
+ working.
Resolved non-showstoppers:
- DERBY-6 Trigger of the form: create trigger ... values myFunction(); has
- no effect.
+ DERBY-6 Trigger of the form: create trigger ... values myFunction();
+ has no effect.
- DERBY-14 Triggers do not evaluate functions in VALUES trigger actions.
+ DERBY-14 Triggers do not evaluate functions in VALUES trigger
+ actions.
- DERBY-21 ResultsetMetaData.getColumnClassName() for CLOB and BLOB datatypes is
- incorrect.
+ DERBY-21 ResultsetMetaData.getColumnClassName() for CLOB and BLOB
+ datatypes is incorrect.
- DERBY-30 Connection.close() method inconsistently throws exception on
- closed connection
+ DERBY-30 Connection.close() method inconsistently throws exception
+ on closed connection
DERBY-35 DRDA Chaining in Network Server is incorrect
- DERBY-38 Make LOCKS as non-reserved keyword in Derby since it is not a
- reserved keyword in the SQL standards
+ DERBY-38 Make LOCKS as non-reserved keyword in Derby since it is not
+ a reserved keyword in the SQL standards
DERBY-40 Cannot set default value for BIGINT
- DERBY-42 When using encryption, do not store the length information about the
- external key in service.properties
+ DERBY-42 When using encryption, do not store the length information
+ about the external key in service.properties
DERBY-44 Support for like ? Escape ?
- DERBY-50 getMaxColumnNameLength() database metadata function returns incorrect
- value.
+ DERBY-50 getMaxColumnNameLength() database metadata function returns
+ incorrect value.
- DERBY-54 'retain' was not a keyword, now it is, possible schema impact
+ DERBY-54 'retain' was not a keyword, now it is, possible schema
+ impact
DERBY-59 dblook currently has driver classes hard coded
- DERBY-67 Network Server on a 64 bit JVM fails with: Execution failed because
- of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 2116; Error
- Code Value = 14
+ DERBY-67 Network Server on a 64 bit JVM fails with: Execution failed
+ because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT
+ arg = 2116; Error Code Value = 14
DERBY-72 IBM (c) message in properties files
@@ -350,21 +374,25 @@
Items deferred to next release:
[PATCH] retrieveMessages... true by default in ij
- The original submitter of this patch (myrnap) requested that it not be applied to
- the current release due to an issue when setting the property on the command-line
- and passing the same property with the connection URL.
+ The original submitter of this patch (myrnap) requested that it not
+ be applied to the current release due to an issue when setting the
+ property on the command-line and passing the same property with the
+ connection URL.
Other applied patches:
- [PATCH] Optimization of org.apache.derby.impl.services.uuid.BasicUUID.toByteArray()
+ [PATCH] Optimization of
+ org.apache.derby.impl.services.uuid.BasicUUID.toByteArray()
[PATCH] Set Derby's build number to be the subversion revision number
[PATCH] derby.war file build
[PATCH] derby.log file error message
[PATCH] Network servlet display only message key
- [PATCH] added 3 more parser generated files to the clobber target in main build.xml
+ [PATCH] added 3 more parser generated files to the clobber target in
+ main build.xml
[PATCH] Various fixes to javadoc generation
[PATCH] Trigger Bug Fix
- [PATCH] Fix to prevent empty log file switches that could cause recovery failures
+ [PATCH] Fix to prevent empty log file switches that could cause
+ recovery failures
[PATCH] ExternalSortFactory Bug Fix
[PATCH] Modify dblook messages to enable localization ...
[PATCH] minor bugs in dblook