[1.35.0] Attention library maintainers: Broken links

I've fixed dozens of the most obvious broken links in Boost.Test documentation, both trunk and release branch. There are still 20 or so broken links left. I find it pretty irritating when the release manager and other volunteers have to fix a library's broken links. This is something that maintainers should check periodically, and fix themselves. The Boost "inspect" tool can be run in any directory to find broken links and other problems in that directory and its sub-directories. That makes it easy to check potential fixes without waiting for the full inspection report to cycle. --Beman

On Mar 18, 2008, at 10:02 PM, Beman Dawes wrote:
I've fixed dozens of the most obvious broken links in Boost.Test documentation, both trunk and release branch. There are still 20 or so broken links left.
I find it pretty irritating when the release manager and other volunteers have to fix a library's broken links. This is something that maintainers should check periodically, and fix themselves.
The release manager should *not* have to do such things. But, that's exactly the kind of thing that tends to take much of the release manager's time :(
The Boost "inspect" tool can be run in any directory to find broken links and other problems in that directory and its sub-directories. That makes it easy to check potential fixes without waiting for the full inspection report to cycle.
Here's a great little project for someone with a little free time: integrate the "inspect" tool into the regression-testing infrastructure, so that any problems found by the inspect program show up as regressions against the library. Each library would have an implicit "inspect" test inspecting that library's sources, documentation, etc. - Doug

Douglas Gregor wrote:
Here's a great little project for someone with a little free time: integrate the "inspect" tool into the regression-testing infrastructure, so that any problems found by the inspect program show up as regressions against the library. Each library would have an implicit "inspect" test inspecting that library's sources, documentation, etc.
Ha! Good idea! Reporting inspection failures as part of normal testing would bring problems to developers attention much earlier in the development process. That's a *good thing*. The inspect program is very fast, so it should not impact build times. I've got a list started of ways to improve the release process, and have added this suggestion. Thanks, --Beman
participants (2)
-
Beman Dawes
-
Douglas Gregor