Dear Graeme,
In message CALButCJ7CG+H-8rOBBiXSdb8_BS13oucgF8QGN53+M0sBrWRCw@mail.gmail.com you wrote:
Yes, I know. Hmmm, maybe if every 24 hours the auto build infrastructure:
- Runs a MAKEALL on the mainline repo (if any patches have been committed)
- Runs a MAKEALL after applying all patches meeting pre-determined conditions. For example:
- All patches passing the automated 'checkpatch'
- All patches which have been ack'd or tested
- All patches applied to sub-repo's (i.e. do a git-pull of each sub-repo)
- If the mainline MAKEALL is clean but the 'patched' MAKEALL is not, use git bisect to identify the first patch that breaks the build
I dare predicting that this will never work. We have some 40+ custodian repos, and automatic pulling all of them at an arbitrary point of time will probably always cause some kind of merge conflicts.
Yes - But see above. If the build infrastructure is building with all the repos applied we will get instant feedback that a repo is out-of-step with mainline rather than waiting for Wolfgang to pull.
For some repos it is more or less the "normal" situation to be not in sync with mainline.
Well, we effectively have: a) Mainline b) Mainline + patches applied to repos
...to a large number (> 40) of repos, all in very different states.
c) Mainline + patched applied to repos + unapplied ack'd patches c) Mainline + patched applied to repos + unapplied ack'd patches + unack'd patches
My thought would be to build test a, b and c every 24 hours and if c passes MAKEALL, do a git apply test on the oustanding patches (and maybe a MAKEALL)
Running a full MAKEALL for all architectures and boards, for all (> 40) repositories, every 24 hours, requires more CPU and I/O cycles that we can currently afford.
We probably need a much more intelligent test build system for such patches:
1) Try to find out which architecture(s) and/or boards are affected: - it modifies files in arch/FOO? Then ARCH=FOO is affected. - it modifies driver BAR? This driver is enabled for the following boards: ... 2) Build a small sub-set (2...5 boards) of the affected boards. 3) Terminate building after the first board that shows new errors or warnings.
Only patches that pass all these tests should be advanced to the next stage, where they get applied to some tree.
Best regards,
Wolfgang Denk