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

[Wolfgang Denk]

Dear Graeme,

In message <CALButCJ7CG+H-8rOBBiXSdb8_BS13oucgF8QGN53+M0sBrWRCw at 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Why is an average signature file longer than an average Perl script??