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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
|