10.3 bug fixing candidates

[Kathey Marsden <km...@sbcglobal.net>]

I was looking through the open issues for good 10.3 bug fixing 
candidates and came up with this list for starters.  If no one objects 
we can go with the same procedure as for 10.2 where we mark high value 
fix candidates  as Fixin the current release. I'll mark these Fixin 10.3 
and update the HighValueFixCandidates page unless anyone objects.

Kathey


DERBY-2370  EXISTS may return the wrong value for sub-queries involving 
set operations
DERBY-889 with client getTimestamp on a TIME column will print the date 
1900-01-01 instead of the current date
DERBY-1030 In some situations a RETURNS NULL ON NULL function is called 
when one of its parameters is null
DERBY-2017 Client driver can insert and commit partial data ...
DERBY-1816 Client's ResultSet.getTime() on a SQL TIMESTAMP column luses 
the sub-second resolution.
DERBY-2381 ParameterMappingTest fails due to ArrayIndexOutOfBoundsException
DERBY-2459 Ordering on a CASE-expression casues a NullPointerException 
when using a UNION
DERBY-2352 Assertion Failure with order by and group by expression
DERBY-2351 ORDER BY with expression with distinct in the select list 
returns incorrect result
DERBY-1816 Client's ResultSet.getTime() on a SQL TIMESTAMP column loses 
the sub-second resolution and always has a milli-second value of zero
DERBY-1782 When a privilege is revoked at table level, Derby should only 
drop objects that require that particular privilege

DERBY-1465 NetworkServerControl.start() should throw an exception and 
not just print exceptions if the server fails to start
DERBY-1256 Remove usage of non-portable methods in derby code
DERBY-1025 [xa] client XAResource.start() does not commit an active 
local transaction when auto commit is true
DERBY-974 ClientDriver can lose some connection properties
DERBY-857 LDAP user authentication fails under a security manager
DERBY-728 Unable to create databases whose name containg Chinese 
characters through the client driver
DERBY-588 database created on zOS (os/390) cannot be used on windows
DERBY-341 Client should disallow XAConnection getConnection() when a 
global transaction has been started and a logical connection has already 
been obtained
DERBY-1018  Client xa Statement.getConnection and 
DatabaseMetadata.getConnection returns underlying NetXAConnection 
instead of Logical connection
DERBY-811 Creating trace files in derbytclient fails when running with a 
SecurityManager

Re: 10.3 bug fixing candidates

[Daniel John Debrunner <dj...@apache.org>]

Kathey Marsden wrote:
> I was looking through the open issues for good 10.3 bug fixing 
> candidates and came up with this list for starters.  If no one objects 
> we can go with the same procedure as for 10.2 where we mark high value 
> fix candidates  as Fixin the current release. I'll mark these Fixin 10.3 
> and update the HighValueFixCandidates page unless anyone objects.

This discussion earlier in the year decided that that using the fixin 
field like that doesn't work. Fixin is to be used when a developer is 
actively working on an issue.

http://mail-archives.apache.org/mod_mbox/db-derby-dev/200701.mbox/%3c45B8C7DE.1080201@apache.org%3e

Dan.

Re: 10.3 bug fixing candidates

[Andrew McIntyre <mc...@gmail.com>]

On 4/13/07, Knut Anders Hatlen <Kn...@sun.com> wrote:
> Kathey Marsden <km...@sbcglobal.net> writes:
>
> > I was looking through the open issues for good 10.3 bug fixing
> > candidates and came up with this list for starters.  If no one objects
> > we can go with the same procedure as for 10.2 where we mark high value
> > fix candidates  as Fixin the current release. I'll mark these Fixin
> > 10.3 and update the HighValueFixCandidates page unless anyone objects.
>
> There was some discussion about the use of Fix-in a couple of months
> ago, and I think we agreed that the Fix-in field should only be used to
> indicate which versions the assignee expected the issue to be addressed
> in. That is, Fix-in should not be set for unassigned issues.

Instead of setting the Fix-in, how about using the Urgency field to
reflect that the bug is a high-value fix?

andrew

Re: 10.3 bug fixing candidates

[Knut Anders Hatlen <Kn...@Sun.COM>]

Kathey Marsden <km...@sbcglobal.net> writes:

> I was looking through the open issues for good 10.3 bug fixing
> candidates and came up with this list for starters.  If no one objects
> we can go with the same procedure as for 10.2 where we mark high value
> fix candidates  as Fixin the current release. I'll mark these Fixin
> 10.3 and update the HighValueFixCandidates page unless anyone objects.

There was some discussion about the use of Fix-in a couple of months
ago, and I think we agreed that the Fix-in field should only be used to
indicate which versions the assignee expected the issue to be addressed
in. That is, Fix-in should not be set for unassigned issues.

See this thread:
http://www.nabble.com/10.3-wiki-page-question-tf3095863.html

-- 
Knut Anders