Hi Marek,
On Sun, Jul 22, 2012 at 12:46 AM, Marek Vasut marex@denx.de wrote:
Dear Graeme Russ,
Patchwork is GPL'd and, in my personal opinion, gets fairly close to what we might need. Maybe we could take Patchwork and modify it to suit our needs?
Maybe ... where're the sources?
git clone git://ozlabs.org/home/jk/git/patchwork
OK, so we already have a fair number of in-house tools that have been developed to get the job done. We have checkpatch.pl, patman, buildman (in development), and Marek's build framework. Why don't we look at integrating these - A modified Patchwork could:
- Automatically run checkpatch and test if the patch applies
But based on tags in the email header, so it'd know against which tree. This is doable, yes!
- Notify the build framework to trigger a build-test
Which might schedule vast MAKEALL across all arches, effectivelly clogging it very soon.
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
- Apply patches to repo's when the maintainer sends an 'Accepted-by:' to the mailing list
Such email can be forged!
- Re-run apply and build tests when a maintainer issues a pull request
You mean when maintainer clicks "Submit pull RQ of this branch" ... then it's rebuild it and only after it passes submit the pullrq?
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.
- Re-run the apply and build tests on all 'staged' patches when patches are committed or branches are merged
Um, what do you mean here?
Well, we effectively have: a) Mainline b) Mainline + patches applied to repos 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)
Regards,
Graeme