mailRe: Integration of the consistency_tests branch (and becoming a relax committer).


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Edward d'Auvergne on December 17, 2007 - 23:33:
On Dec 17, 2007 9:19 PM, Sebastien Morin <sebastien.morin.1@xxxxxxxxx> wrote:

 Hi Ed,

 The consistency tests code is now fully integrated into the 1.2 line...

I'll try to release a new relax version soonish with this new code.
Hopefully I'll have time before this weekend, otherwise it will have
to wait until after the new year as I'll be on holidays.


 Thanks for the help concerning SVN !

That's no problem.


 For the consistency tests code in the 1.3 line, I would like to start the
work as soon as possible.
 Do I have commit access to this branch ?

You have full commit access to everything, including the webpages.  So
you can modify anything you like.  Changes will need approval though.
And I would prefer that most development occur in branches and then
after I review and accept the code it can be merged into the main
lines.  The exception is the 1.3 line redesign which is going directly
into that line.  Because the changes are so massive, a development
branch for this makes no sense.


 Would it be a good idea to merge the changes that happened in the 1.3 line
to the branch before starting the work (However, svnmerge does not seem to
have been initialized in this branch right now.) ?

It is best to keep up to date.  The internal changes since the branch
have been immense and very radical!  You will need to initialise
svnmerge on the branch from the revision at which the branch was
created.  You can use svnmerge to keep your branch up to date.  A word
of warning though, with my current 1.3 line code changes, I regularly
make relax fail before getting to the prompt.  So I would run the
test-suite on the 1.3 line prior to each use of svnmerge.

I would also recommend creating a few unit tests for each user
function and each function in the specific_fns and maths_fns code.
Gary's unit test framework is a very powerful technique for weeding
out bugs.  This tests the proper behaviour of individual functions and
their failure.  From the 400 unit tests I have written so far, you
should get a good idea there of what to do.  I highly recommend adding
tests here.  I have been doing all of the new development by writing
comprehensive unit tests prior to the actual code.  Then I write the
code for relax and debug until the tests pass, at which point the code
is very clean.  If I then realise I need to redesign something or make
it more flexible, this net of unit tests then makes this code
refactorisation very quick, especially for debugging.

Cheers,

Edward



Related Messages


Powered by MHonArc, Updated Tue Dec 18 00:01:51 2007