Re: [boost] [1.35.0] Tickets, Milestone, Testing

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