Re: [Vote] Guidelines to avoid regressions.

[Nicola Ken Barozzi]

[EMAIL PROTECTED] wrote:

2 guidelines to avoid regressions. I believe proposals guideline is part of Jakarta, and James has used it effectively.

1. Have risky or major refactoring in the proposals area and move them to
head after there has been some testing and review.

Usually, to reduce code moves, branches are used.

I would propose that for new features, a new CVS module is used, called james-sandbox. This has been done in Avalon because keeping things in the same module can sometimes make the code appear as if it were almost in the core, which at this stage it is not. To move it to the main module, there must be a vote.

If the feature is a refactoring, a branch should be used, and a majority vote at least should pass to make the switch of the branches.

2. Run a minimal end user test(say something that can be done in 5 mins)
after refactoring.

The end-user test should really be done with functional and unit tests. Because we cannot assume that every programmer has Outlook Express or can remember what to test every time.

For unit tests there is Junit.
For functional tests Anteater.
To record tests maybe JMeter.

Probably some additions have to be done to these to make them work with James, but I'm sure Jeff and Ovidiu of Anteater would be more than helpful on this.

Of course if it is automated all the better.

Of course, but you are right that developers should run them before committing too.
The Gump runs would just be another safety net.

Could this be incorporated into a set of project guidelines for James. I
believe it would make everybody more productive. As James grows in
size/ambition some simple guidelines could yield a lot of benefit.

IMHO these guidelines are *essential* in an OS project to make it proceed well with good and stable quality.

James/Apache developers are a talented group but it is possible to miss
things as each person usu. has more than enough things on the plate.

Exactly.

Cocoon is having too many regressions lately, all because we don't have unit tests. I basically overlook the exception handling code, but it keeps breaking, because its concerns are scattered all over the place, in every place where an exception is thrown, catched, rethrown...
Discipline is not enough, because I can assure you that in the Cocoon project we are all very careful on this, but we are only human.

I'm quite sure that an OS project needs tests to be able to remain stable, highquality, and survive the knowledge of single programmers.

If you write down the guidelines, I may as well add them as a note to the incubator project and ask Avalon, Cocoon, Forrest and POI to follow them.

--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>