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

[Marek Vasut]

Dear 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

Yep, found it recently ... I can't do python and I don't have the capacity to 
learn it now, any volunteers?

> >> 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)

Certainly ... it takes 16 hours to do so on my dedicated machine though (more 
now, since I started building sparc too ;-D ). But WD has some pretty badass 
machines that can do it really quick :-)

>  - 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

Or simply build it again and again, with patches that passed checkpatch applied 
and do one big build of the main repo every 24 hours if patches were added.

And if the patches passed compile-testing, we can mark them somehow.

>     - 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

Hm yea ... serverfarm needed here. Badass machines and badass cluster is a 
difference ;-)

> >>  - 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.

Uh, I think my english decoder got clogged somewhere in here ... can you 
ignore/abort/retry please ? ;-)

> >>  - 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)

You have c) twice in there (nit :) ). Still, we'd need a pretty badass 
buildsetup for that, right? But indeed, such an algo sounds nice.

> Regards,
> 
> Graeme

Best regards,
Marek Vasut