2006/11/4, Weldon Washburn <[EMAIL PROTECTED]>:
Folks,
I have spent the last two months committing patches to the VM. While we
have added a ton of much needed functionality, the stability of the system
has been ignored. By chance, I looked at thread synchronization design
problems this week. Its very apparent that we lack the regression testing
to really find threading bugs, test the fixes and test against regression.
No doubt there are similar problems in other VM subsystems. "build test"
is necessary but not sufficient for where we need to go. In a sense,
committing code with only "build test" to prevent regression is the
equivalent to flying in the fog without instrumentation.
So that we can get engineers focused on stability, I am thinking of coding
the JIRAs that involve new features as "later" or even "won't fix". Please
feel free to comment.
I prefer to move the issue to the next milestone or release if I'm not
sure that it will not break stability of the product and we are in
"near release" phase.
Probably it's time to create some release plan :)
I think it will make many things much easier. If we will have a list
of features for release and release date it will be much easier to
decide do we want to apply the fix or postpone it to the next release.
So let's start this discussion?
SY, Alexey
We also need to restart the old email threads on regression tests. For
example, we need some sort of automated test script that runs Eclipse and
tomcat, etc. in a deterministic fashion so that we can compare test
results. It does not have to be perfect for starts, just repeatable and
easy to use. Feel free to beat me to starting these threads :)
--
Weldon Washburn
Intel Enterprise Solutions Software Division
