octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: test scripts


From: John W. Eaton
Subject: Re: test scripts
Date: Mon, 1 May 2000 04:21:45 -0500 (CDT)

On  2-May-2000, Paul Kienzle <address@hidden> wrote:

| There are a two ways to deal with problem patches.  One is to aggressively
| train people to produce patch the way you want by rejecting any that
| don't meet your standards.  The other is to deputize.  That is, let 
| a few others massage patches and interact with submitters, then send
| you clean patches to decide upon.  So far this style is working for the
| kernel, and it has A LOT more activity than octave.

And a lot more contributors and people willing to work on it, I think.
It is possible that my current management style doesn't encourage as
many contributors as it could, but I would guess that the real problem
is that there are just fewer people who are good programmers and also
interested in numerical software than there are good programmers who
are interested in kernel hacking.

Some people have suggested that by being more open (putting any old
rotten patch in as quickly as possible, etc.) Octave would attract
more interest.  But I don't think that would be good for quality, so
I'm not likely to do it.

| If you
| are particularly concerned about the format of code, then write a
| pretty printer to format it exactly the way you want it.

Sure.  Octave's type command does almost enough, except that it
doesn't handle comments.  Lately I've done a little work to improve
that, so maybe this is the best solution.

| The bigger problem to my mind is deciding if the patches produce
| correct code.  A testing mechanism that mere dabblers can use with
| most of the tests already defined is a big step in the right direction.
| I've needed enough brown bags in my few submissions that I'm motivated
| to work on it.

I think the stuff you've done for the tests is moving in the right
direction.  I've never really liked using DejaGNU as a testing tool.
It's nice that it can continue after a test causes a crash, but it
seems relatively complex, and the current tests have a lot of overhead
because each test requires starting a new copy of Octave.

I've never looked closely at the tests for perl, but I believe that
perl is used to run the tests.  If there is some serious bug that
causes perl to crash during the tests, does it recover gracefully?

I don't suppose it really matters that much, since I'd normally want
to fix any bug that caused a crash in a test immediately, and then
work on fixing other things, though I suppose if the problem were too
hard to fix quickly, I would just temporarily disable the test.

Thanks,

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]