In the past month, I've devoted many hours to testing my submissions, but clearly the effort is not achieving the goal. I request some help to understand how I can improve my pre-commit testing procedures, and where my responsibilities begin and end. I enjoy having my commits reverted as much as others enjoy having their build broken--it is a big waste of pro-bono time--so I want to understand the issues clearly.
How are build-breaking changes getting into the master branch? CG section 3.4.10 says that the reason for pushing to staging is that automated tests are run before changes are moved to master. What specifically is being tested? And days before that happens, patches are announced as having been tested with the feedback "Passes make. make check and a full make doc." The evidence suggests that that does not include running autogen, otherwise it should have caught the problem with "tidy" that my own testing failed to catch. Should things such as missing optional programs and new-ish Python syntax be rejected at either of these stages? If not, then it would seem to fall to the submitter to set up an alternate development environment with Python 2.4, GCC 3.4, and similarly aged versions of other tools, and run additional tests in that environment. Thanks, — Dan