[U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Graeme Russ]

Hi Marek,

On Sun, Jul 22, 2012 at 12:46 AM, Marek Vasut <marex at 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