Hi Marek,
On Sun, Jul 22, 2012 at 12:46 AM, Marek Vasut <ma...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
