Such model works but there is a risk of fixing again "from scratch" those
bugs which were fixed once on the previous milestones.

We can eliminate this if follow "no regression" policy - if something works
(classlib unit tests, Tomacat or Eclipse Unit Tests pass 100%, for example),
it should continue working - any regression is a subject for reporting and
fixing as soon as possible (it is easier to find root cause and fix since we
will know which commit caused regression).

Will this model work? Isn't it a little bit better than focusing on runtime
stability periodically?


On 11/8/06, Tim Ellison <[EMAIL PROTECTED]> wrote:

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.

Reply via email to