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
