[Vote] Guidelines to avoid regressions.

[ha...@kodemuse.com]

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.

2. Run a minimal end user test(say something that can be done in 5 mins)
after refactoring. Of course if it is automated all the better.

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.

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. A check list and self discipline may help even the best.

thanks,
Harmeet

Re: [Vote] Guidelines to avoid regressions.

[Nicola Ken Barozzi <ni...@apache.org>]

harmeet@kodemuse.com 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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>