In my opinion we are ready to make a release candidate. I was out
during the recent license workaround discussion. I think the proposed
workaround is reasonable and it is about time to get this release out.
At this point I don't think there are easy hard/fast rules. In your
example maybe we would hold back because there was a large number of
such issues, vs. 1.
I agree with rick that I would not hold up 10.2 release for a reported
and as yet unfixed bug for an existing
issue in 10.1.3, even if it worked in 10.1.2. If there was an existing
patch to fix, then I might consider it.
But at this point it is all about weighing the value to users who have
been waiting a long time for 10.2 vs. delaying for "one last bug". At
this point it would take a very serious regression for me to think we
should hold up - something like a db corruption regression. I think it
would even be ok to go out with less serious regressions, documenting
what they are and making them high priority for gettting them fixed in
the branch ASAP. This is opensource, once they are in the branch anyone
who cares enough can get it immediately.
With this specific bug I think the "good" news (for some twisted
definition of "good"), is that a user running into the problem will know
it as they will get an error of some kind (vs. a wrong result).
Hopefully this will lead them to the DERBY-1866 discussion of the
outstanding issue.
I do think that at this point we should get all the relevant patches in
the trunk merged into the 10.2 branch, and committers should take a
careful look at outstanding patches to make sure all that make sense
are in 10.2.
A B (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1866?page=comments#action_12436637 ]
A B commented on DERBY-1866:
----------------------------
As I understand it, this bug exists in the 10.1.3 release. It seems that, as
far as this bug is
concerned, 10.2 is no worse than 10.1.3. For that reason, I would not be
inclined to hold up
the 10.2 release for this bug fix.
Two things:
1. Are we going to mention the known issues (esp. regressions) that exist with the 10.2
release (aside from intentional behavioral changes) somewhere in the release notes? I
looked at the html file attached to DERBY-1860 and didn't see any (the "issues"
section just holds release notes for intentional behavior changes and/or fixes). Are we
just leaving it up to the users to navigate Jira to find outstanding issues like
DERBY-1866?
2. Just as a note, this reasoning for not holding up the release also applies to DERBY-1777,
DERBY-1633, and DERBY-1681, since all of those fail with 10.1.3 release, as well. (Oh, and
*DERBY-1854*, for that matter!) Am I to understand that if any of those was still unresolved,
we'd go ahead with the release nonetheless? I'm not disagreeing with the decision, just
curious if the "it's no worse than <previous release>" rule is specific to this
particular Jira or if it applies on a more general scale?
Thanks for following through with this discussion and making a final decision!
Assert failure in sane mode for queries that used to work in 10.1.2.1
---------------------------------------------------------------------
Key: DERBY-1866
URL: http://issues.apache.org/jira/browse/DERBY-1866
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.1.0, 10.1.4.0, 10.1.3.2
Reporter: A B
Assigned To: A B
Fix For: 10.2.2.0
Attachments: derby.log, repro.sql
Derby-1777 gives a database and a small program called "ViewerInit" that
prepares a bunch of large queries involving nested subqueries, unions, and join
predicates. The actual bug described in DERBY-1777 is an NPE, and that's what the patch
for DERBY-1777 addresses.
However, once the NPEs are fixed, some of the queries in that same program now
fail with ASSERT failures when running in SANE mode; this Jira issue is for
addressing those assert failures.
While this does constitute a regression, I don't know yet what the root cause of the
problem is, so I hesitate to make it a 10.2 blocker--hence urgency is "Normal".
I'm still investigating the queries to try to track down where the problem is, but all
I've been able to deduce so far is that a) the assertion occurs for a scoped predicate
and thus the pushing of join predicates into UNIONs is somehow involved, and b) in INSANE
mode the query compiles without problem and appears (based on some early and very
incomplete testing) to execute without problem. But more investigation is required to
determine if the execution/results are actually correct, and to understand more about why
the assertion is being thrown.
I'm marking the fixin as 10.2.2.0 for now since I don't enough to make this a
blocker for 10.2.1. Hopefully more info will be forthcoming...
