I wouldn't go so far as to label issues as "won't fix" unless they are really high risk and low value items.
It's useful to go through a stabilization period where the focus is on getting the code solid again and delaying significant new functionality until it is achieved. A plan that aims to deliver stable milestones on regular periods is, in my experience, a good way to focus the development effort. Regards, Tim Weldon Washburn wrote: > 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. > > 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 :) > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
