Re: dlclose()

[cgf at cygnus dot com (Chris Faylor)]

In article <b7lfzhkj6.fsf@rtl.cygnus.com>,
Jim Kingdon  <kingdon@redhat.com> wrote:
>I'd probably argue that the distributed testing resulting from getting
>patches checked in is more effective QA than getting obsessed with
>testsuites but that isn't really the point in the sense that I'd like
>to see both.

Since running the testsuite should be a relatively trivial sanity test I
don't see why you would even raise the issue of "getting obsessed".

For the record *I'd* like to see people run a test suite on their
machine before a patch even makes it to gdb-patches.  I don't see any
reason why you would expect somebody else to take time to test out your
potentially buggy patch submissions.

We've already seen at least one recent case where a test suite run prior
to an overly optimistic check-in would probably have saved people from
breakage.  I would think that that was argument enough for adopting this
practice.

"Distributed testing" means "distributed confusion" when problem source
code makes it into the repository.  It means that we will invariably see
the same problem reported to various gdb mailing lists multiple times.
That means more work for the people who report the problem as well as
more work for people who are responding to the people who report the
problem.

Of course it is inevitable that there will be breakage when somebody
checks in a patch.  However, if we have a tool for reducing the
potential for breakage even slightly, we should use it.  At Cygnus/Red
Hat, we actually have a policy that no checkins are to be made without
checking a test suite run for regressions for just this reason.
-- 
cgf@cygnus.com                        Cygnus Solutions, a Red Hat company
http://sourcware.cygnus.com/          http://www.redhat.com/