Re: [Boost-docs] Inspection report failures

Subject: Re: [Boost-docs] Inspection report failures
From: Beman Dawes (bdawes_at_[hidden])
Date: 2009-07-25 15:35:12

On Wed, Jul 22, 2009 at 4:39 PM, troy d. straszheim<troy_at_[hidden]> wrote:
> Daniel James wrote:
>>
>> 2009/7/22 Beman Dawes <bdawes_at_[hidden]>:
>>>
>>> http://boost.cowic.de/rc/inspect-snapshot.html is the latest release
>>> candidate inspection report. If you click on the "Worst Offenders", it
>>> looks
>>> as if many of the detail failures are license failures in generated .html
>>> files.
>>>
>>> What can we do about these failures? They are obscuring more important
>>> failures I would like to start attacking.
>>
>> Gennadiy will have to deal with the failures in the test documentation
>> as he doesn't seem to have checked in the source code.
>>
>> The failures in the 'doc' directory seem to be from variant, any,
>> concepts and boost build. I think I can just add the license since all
>> the authors are in the blanket permission file (apart from HP for
>> concepts, so I'll leave their license in place) - it just requires the
>> boost copyright to be added to the library information in the
>> boostbook/quickbook source.
>
> Oops, Beman, I owe you a bunch of license fixes, sorry.  Getting right on
> it.

Troy,

Thanks for making the license fixes to branches/release.

The same set of changes also need to be made to trunk.

Changes to branches/release always need to made to trunk (either
first, and then merged to branches/release, or more exceptionally as a
separate set of changes to each). There are at least two problems with
making changes only to branches/release:

* Changes to branches/release that don't also appear in trunk stand a
great chance of being wiped out by subsequent tree/tree merges.
Developers assume tree/tree merges are safe because they assume no
changes to branches/release for their library is ever made without
first changing trunk.

* Unmerged changes analysis using svn diff become useless. That's how
I realized there was a problem; I started to do an unmerged changes
analysis and got a bunch of false positives.

Thanks,

--Beman