You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Rick Hillegas <ri...@oracle.com> on 2012/04/11 18:16:01 UTC
10.9 release
I am volunteering to manage a 10.9.1 feature release. Please let me know
if you are comfortable with the plan posted here:
http://wiki.apache.org/db-derby/DerbyTenNineOneRelease The plan calls
for a first release candidate on May 21 and GA on June 20.
At this time, I see that we have 2 blocker issues, both related to the
behavior of sequences and identity columns. I'm cautiously optimistic
that we can close these issues by the middle of May.
DERBY-5495 (master issue for problems with sequences and identity columns)
DERBY-5422 (exceptions in NsTest)
Please let me know if you see other issues which should block a 10.9.1
release. As always, feel free to add more detail to the 10.9.1 planning
page.
Thanks,
-Rick
Re: 10.9 release
Posted by "Dag H. Wanvik" <da...@oracle.com>.
Rick Hillegas <ri...@oracle.com> writes:
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12313481
The two reported by me (5622, 5546) can probably be deferred since they
are edge cases.
Thanks,
Dag
Re: 10.9 release
Posted by Myrna van Lunteren <m....@gmail.com>.
I am on board doing my usual testing for the period you are aiming
for. I think it's a good time - if you plan later people (including
myself) will be on vacation.
However, there are a number of frequent intermittent test failures
that my automated test runs are suffering from...If at all possible,
I'd like them addressed before a candidate...
Here's the list of the last two weeks:
- https://issues.apache.org/jira/browse/DERBY-5197:
(AssertionFailedError: Could not connect in 20000 ms in
ReplicationRun_Local_3_p2.testReplication_Local_3_p2_StateTests_bigInsert_immediateStopMaster
)
Note: I run with -Dderby.tests.networkServerStartTimeout=480.
- https://issues.apache.org/jira/browse/DERBY-5686
(java.sql.SQLException: An SQL data change is not permitted for a
read-only connection, user or database.)
There's possibly a test somewhere that leaves behind database
property settings for read-only database. I'm trying to find such a
test.
- https://issues.apache.org/jira/browse/DERBY-5600
(replicationTests.ReplicationRun_Local_1Indexing)junit.framework.AssertionFailedError:
Failover did not succeed)
- https://issues.apache.org/jira/browse/DERBY-5667 - (Missing rows in
ResultSet in store.UpdateLocksTest).
I am looking into this.
The theory is that the 'missing rows' are locks, and that the lack of
them is due to background threads handling post-commit tasks.
So I'm working towards adding some debugging code to capture the
error and adding WAIT_FOR_POST_COMMIT (similar to what's in
LargeDataLocksTest.java).
- https://issues.apache.org/jira/browse/DERBY-4852 (50 errors,
starting with JMXTest, connection failed with
javax.naming.ServiceUnavailableException & related).
- https://issues.apache.org/jira/browse/DERBY-5666
(NativeAuthenticationServiceTest : Database restoration unexpectedly
failed)
I don't think the release should be held up because of these issues.
Myrna
Re: 10.9 release
Posted by Rick Hillegas <ri...@oracle.com>.
On 4/18/12 11:23 AM, Katherine Marsden wrote:
> ...
>
> I can get DERBY-5565 in, but won't have time to pick up the other two
> before the proposed release candidate date. Might someone else be
> able to pick these up? I think they are small high value items but
> have to be done in feature release I think.
>
I agree that data corruptions are the top priority, with highest
priority going to ones with repros like DERBY-5565. I see 13 data
corruptions on this list:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12313481
Thanks,
-Rick
Re: 10.9 release
Posted by Kim Haase <ca...@oracle.com>.
On 04/18/12 02:23 PM, Katherine Marsden wrote:
> On 4/11/2012 10:00 AM, Rick Hillegas wrote:
>> Hi Kathey,
>>
>> Can you give us more detail about what makes this testing burden
>> increase dramatically with each new release? At first blush, it seems
>> to me that the burden should increase linearly and therefore the
>> expense should be hidden by the more than linear increase in machine
>> power over time. Maybe there is some tooling we could build or
>> simplification we could investigate which would reduce this increase
>> to a linear problem.
> I was trying to find your excellent email a while back explaining the
> number of upgrade/downgrade trajectories, client server combinations,
> jvm's and the length of time (as I recall years) it would take to do
> basic testing on all of them.
> I will look some more and work the numbers and then start a new thread
> on the topic.
>
>>>
>>> Are there pressing needs that necessitate a 10.9 vs a 10.8.3 right away?
>> I would like to get NATIVE authentication into users' hands. I'd also
>> like to see the remaining bits of JDBC 4.1 go GA.
> Definitely good to get these things out there. Perhaps we can integrate
> a bug fix effort to drive down the backlog. I started a triage effort at:
> http://wiki.apache.org/db-derby/DerbyTenNineBugTriage
>
> I think most of the bugs except Replication and Documentation have been
> triaged through January. Wouldn't take much to get that up to date with
> recent issues and add some lists for High value fixes etc to the 10.9
> page if that is ok. Alternately I could make a separate 10.9 bug fixing
> drive page.
>
> I think the most important fix to get in for 10.9 is DERBY-5234. We
> shouldn't do a release with a known corruption issue like that. If we
> are putting out a feature release. It would sure be gret to see the
> following fixed too instead of waiting for 10.10:
>
> DERBY-4805 Increase the length of the RDBNAM field in the DRDA
> DERBY-5578 Provide a way to invalidate stored prepared statements
> DERBY-5565 Network Server should reject client connections that are not
> Derby Network Cli
> <https://issues.apache.org/jira/browse/DERBY-5565>
>
> I can get DERBY-5565 in, but won't have time to pick up the other two
> before the proposed release candidate date. Might someone else be able
> to pick these up? I think they are small high value items but have to be
> done in feature release I think.
>
> Lastly, couple of important doc issues would be great to get in too to
> decrease the frequency and pain of corruptions:
>
> DERBY-5691 Document that Write Caching must be disabled to avoid
> possible database corruption
I looked at this and will pick it up. I may need some help, though,
figuring out where best to put this information.
> DERBY-5508 Improve backup/restore documentation visibility and content
> to encourage proper backups and restore procedures
You read my mind -- I'm about to file a preliminary patch for this,
though I asked a few questions yesterday to which it would be helpful to
get answers before the next patch.
Kim
>
>
>>> I think it might be good to do one more 10.8 release before 10.9.
>> Another 10.8 release sounds like a good idea for people who want
>> targetted bug fixes on a stable codebase. I have no objection to
>> someone else producing a 10.8.3 release.
>>
>
> I will try to manage a 10.8.3 shortly after 10.9 goes out and
> incorporate the portable fixes we get into trunk as part of the 10.9 bug
> fixing effort.
>
>
> Kathey
Re: 10.9 release
Posted by Katherine Marsden <km...@sbcglobal.net>.
On 4/11/2012 10:00 AM, Rick Hillegas wrote:
> Hi Kathey,
>
> Can you give us more detail about what makes this testing burden
> increase dramatically with each new release? At first blush, it seems
> to me that the burden should increase linearly and therefore the
> expense should be hidden by the more than linear increase in machine
> power over time. Maybe there is some tooling we could build or
> simplification we could investigate which would reduce this increase
> to a linear problem.
I was trying to find your excellent email a while back explaining the
number of upgrade/downgrade trajectories, client server combinations,
jvm's and the length of time (as I recall years) it would take to do
basic testing on all of them.
I will look some more and work the numbers and then start a new thread
on the topic.
>>
>> Are there pressing needs that necessitate a 10.9 vs a 10.8.3 right away?
> I would like to get NATIVE authentication into users' hands. I'd also
> like to see the remaining bits of JDBC 4.1 go GA.
Definitely good to get these things out there. Perhaps we can integrate
a bug fix effort to drive down the backlog. I started a triage effort at:
http://wiki.apache.org/db-derby/DerbyTenNineBugTriage
I think most of the bugs except Replication and Documentation have
been triaged through January. Wouldn't take much to get that up to date
with recent issues and add some lists for High value fixes etc to the
10.9 page if that is ok. Alternately I could make a separate 10.9 bug
fixing drive page.
I think the most important fix to get in for 10.9 is DERBY-5234. We
shouldn't do a release with a known corruption issue like that. If we
are putting out a feature release. It would sure be gret to see the
following fixed too instead of waiting for 10.10:
DERBY-4805 Increase the length of the RDBNAM field in the DRDA
DERBY-5578 Provide a way to invalidate stored prepared statements
DERBY-5565 Network Server should reject client connections that are not
Derby Network Cli
<https://issues.apache.org/jira/browse/DERBY-5565>
I can get DERBY-5565 in, but won't have time to pick up the other two
before the proposed release candidate date. Might someone else be
able to pick these up? I think they are small high value items but have
to be done in feature release I think.
Lastly, couple of important doc issues would be great to get in too to
decrease the frequency and pain of corruptions:
DERBY-5691 Document that Write Caching must be disabled to avoid
possible database corruption
DERBY-5508 Improve backup/restore documentation visibility and content
to encourage proper backups and restore procedures
>> I think it might be good to do one more 10.8 release before 10.9.
> Another 10.8 release sounds like a good idea for people who want
> targetted bug fixes on a stable codebase. I have no objection to
> someone else producing a 10.8.3 release.
>
I will try to manage a 10.8.3 shortly after 10.9 goes out and
incorporate the portable fixes we get into trunk as part of the 10.9 bug
fixing effort.
Kathey
Re: 10.9 release
Posted by Rick Hillegas <ri...@oracle.com>.
Hi Kathey,
Thanks for the quick response. Some comments inline...
On 4/11/12 9:29 AM, Katherine Marsden wrote:
> On 4/11/2012 9:16 AM, Rick Hillegas wrote:
>> I am volunteering to manage a 10.9.1 feature release. Please let me
>> know if you are comfortable with the plan posted here:
>> http://wiki.apache.org/db-derby/DerbyTenNineOneRelease The plan calls
>> for a first release candidate on May 21 and GA on June 20.
> Since the number of upgrade/downgrade trajectories and mixed client
> server versions increases dramatically with each new version, along
> with more builds and tests with multiple jdk versions and platforms
> to track. I would think maybe a bug fix drive followed by a 10.8.3
> release and then a 10.9 late in the year with more than the short list
> of features we have on the 10.9 list would be good.
Can you give us more detail about what makes this testing burden
increase dramatically with each new release? At first blush, it seems to
me that the burden should increase linearly and therefore the expense
should be hidden by the more than linear increase in machine power over
time. Maybe there is some tooling we could build or simplification we
could investigate which would reduce this increase to a linear problem.
>
> Are there pressing needs that necessitate a 10.9 vs a 10.8.3 right away?
I would like to get NATIVE authentication into users' hands. I'd also
like to see the remaining bits of JDBC 4.1 go GA.
> I believe release early, release often is good, but because of the
> explosive nature of maintenance with each new major release, I think
> it might be good to do one more 10.8 release before 10.9.
Another 10.8 release sounds like a good idea for people who want
targetted bug fixes on a stable codebase. I have no objection to someone
else producing a 10.8.3 release.
Thanks,
-Rick
>
> Just my opinion.
>
> Kathey
>
>
>
Re: 10.9 release
Posted by Katherine Marsden <km...@sbcglobal.net>.
On 4/11/2012 9:16 AM, Rick Hillegas wrote:
> I am volunteering to manage a 10.9.1 feature release. Please let me
> know if you are comfortable with the plan posted here:
> http://wiki.apache.org/db-derby/DerbyTenNineOneRelease The plan calls
> for a first release candidate on May 21 and GA on June 20.
Since the number of upgrade/downgrade trajectories and mixed client
server versions increases dramatically with each new version, along with
more builds and tests with multiple jdk versions and platforms to
track. I would think maybe a bug fix drive followed by a 10.8.3 release
and then a 10.9 late in the year with more than the short list of
features we have on the 10.9 list would be good.
Are there pressing needs that necessitate a 10.9 vs a 10.8.3 right
away? I believe release early, release often is good, but because of
the explosive nature of maintenance with each new major release, I think
it might be good to do one more 10.8 release before 10.9.
Just my opinion.
Kathey