Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

[Dan Eble]

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