Subject: PRs, change control, testsuites (Re: Diaspora, politics, and MI)
To: None <current-users@NetBSD.ORG>
From: Antti Miettinen <firstname.lastname@example.org>
Date: 09/20/1996 00:20:10
>My experience has been that most bug reports do not include fixes.
>This is unfortunate, because a volunteer project really needs for
>people to take the time to try to come up with fixes...
Hmm.. I would consider it at least a bit helpful if people take the
time to write good bug reports.
I haven't supped in a long time. What is the situation with testsuites
nowadays? It would be great if there was a testsuite being expanded
with a case for each bug found. I suppose we unskilled might be able
to come up with test cases if not fixes. This would require some kind
of framework for making the tests. Obviously the testcases should be
automatically runnable and it should be possible to collect the
results of a number of test cases.
Curt Sampson writes:
>willing to trust someone they don't know (say, me) to test this
>fix, so that they don't have to do it themselves?
Now what can be considered "testing"? No-warning compile? A succesfull
boot for the kernel? A week uptime?
Jason Thorpe touches the issue by writing:
>It's also important that bug fixes
>don't introduce new bugs.
To validate this there should be a testsuite which accumulates test
cases for each bug. Of course we can't expect that core tests
everything in every possible combination so this would be perfect
place for us unskilled to help. I suppose anyone is able to sup, make
check and send-pr a log file :)
I personally like the fact that there is some kind of change control
policy for NetBSD. It looks like a real software process - not just
happy hacking :)
Maybe I'm being pendantic but where I work, version management,
configuration management, change control, testing, controlled
documented process etc is almost a religion compared to what seems to
be the industry standard (have you seen Lotus Notes? It can say
"Memory allocation exceeded 65000 bytes" on Windows NT).