From: David Abrahams (dave_at_[hidden])
Date: 2007-11-05 13:01:51
on Thu Nov 01 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
> David Abrahams wrote:
>> on Thu Nov 01 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
>>> David Abrahams wrote:
>>>> on Wed Oct 31 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
>>>>> David Abrahams wrote:
>>>> Patches should only be a high priority if they fix bugs... and in that
>>>> case they should come with a test that breaks until the bug is fixed.
>>> It is very useful and a sign of good software engineering if a test case
>>> accompanies a bug fix. But patch submitters don't always have enough
>>> time or knowledge of a library's test setup to submit test cases. I'd
>>> rather fixes be prioritized based on severity rather than whether or not
>>> they come with a test case.
>> When I say "come with" I mean they should come into our source
>> repository with a test case, which may be supplied by anyone,
>> inlcuding the library maintainer. I don't think we should be just
>> applying "bug fix" patches without being able to confirm that they
>> actually fix bugs.
> I don't know how to do that for system specific fixes on platforms Boost
> isn't testing and I don't have access to. For libraries like
> Boost.System and Boost.Filesystem I have to take such patches on faith.
> Of course I inspect them to make sure they appear reasonable and don't
> affect other platforms.
The person submitting the patch surely describes to you the problem
the patch should be fixing, no?
If you don't have access to the platform, create a test and tweak
until it fails in the way described.
> What you are saying is certainly the "right way" most of the
> time. But it is hard to do for some of the more obscure platforms.
I don't know; I guess I'd be very reluctant to patch my code with a
correction for a problem until it's reproduced.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk