Changes between Version 2 and Version 3 of SuggestionsForOneDotThirtySix
- Timestamp:
- Mar 27, 2008, 4:51:05 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
SuggestionsForOneDotThirtySix
v2 v3 15 15 * Consider giving several people access to the machines that run trunk and release reporting. 16 16 17 * Refuse commits that would cause inspection errors. Inspection errors are time consuming, and slow release progress. The earlier they can be detected, the easier they will be to fix. Details need to be worked out. 17 * Refuse commits that would cause inspection errors. Inspection errors are time consuming, and slow release progress. The earlier they can be detected, the easier they will be to fix. Details need to be worked out. [This involves adding a new Subversion hook to the existing checks] 18 18 19 * Feed inspection errors into the regression reports, so that inspection problems are much more obvious. [Suggested by Doug Gregor .]19 * Feed inspection errors into the regression reports, so that inspection problems are much more obvious. [Suggested by Doug Gregor; note that this becomes less important if we have the aforementioned Subversion hook] 20 20 21 21 * Feed trac bug reports into the regression reports, so that outstanding tickets for the release-in-process are more obvious. 22 22 23 * Make sure daily full inspection is run on '''both''' trunk and release. 23 * Make sure daily full inspection is run on '''both''' trunk and release. [Doug: if Subversion is doing these checks, does it matter?] 24 24 25 * Automatic install tests should be run on the daily snapshots to verify install isn't broken. Need to design way to automatically detect install failures, and report them to the list (perhaps by email). Two tests are needed, one for Windows, one for Linux. If those are working, the chance of failures on other platforms is much reduced. 25 * Automatic install tests should be run on the daily snapshots to verify install isn't broken. Need to design way to automatically detect install failures, and report them to the list (perhaps by email). Two tests are needed, one for Windows, one for Linux. If those are working, the chance of failures on other platforms is much reduced. [Doug Gregor: in an ideal world, we would build+install, then perform testing against the installed tree] 26 26 27 27 * Recognize that infrastructure changes (new Boost.Build version, new testing procedures, new web site organization, new directory tree organization, etc.) have a history of being very disruptive and markedly slowing release progress.
