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

[Marek Vasut <marex@denx.de>]

Dear Graeme Russ,

[...]

> >> Maybe it's time to seriously look at a gerrit + jenkins based solution?
> > 
> > I am not sure that gerrit will solve any of the problems we have.
> > I may be missing it, but for example I don't see any integration into
> > a mostly e-mail based work flow.  From what I have seen so far (which
> > is not much, I admit) it appears we would again add another tool that
> > in the first place requires additional steps which interrupt the work
> > flow. Speaking for myself, this is a killing point.
> 
> There are a few things I don't like about gerrit:
>  - Not based on an email-centric workflow

+1

>  - Need to 'drill-down' to get to the actual patch
>  - UI is overly verbose

Add
- it's java crap, prone to breakage.
- it's overengineered

And ad. jenkins -- with all that plugins infrastructure, it's so vast it can 
even make coffee and bake a cake damned!

> But there are other things I do like:
>  - Maintains the revision history of each patch

If you follow some rules though :/

>  - Keeps track of review status

Not so usable tho

>  - Keeps track of the what branch the patch is against

Yes?

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

> > And Jenkins... well, we have been using this for some time internally
> > to run test builds for U-Boot.  I can tell you a thing or two about
> > it, and Marek has his own story to tell about his experiences when he
> > added to the build matrix.
> > 
> > As is, we try hard to get rid of Jenkins, because it does not scale
> > well to the type of builds we want to be able to do.  Marek even
> > started setting up his own test build framework...
> 
> 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.

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

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

> I short, we have three options
>  - Modify our workflow so we can use existing tools
>  - Modify existing tools and/or create new tools to match our existing
>    workflow
>  - A bit of both
> 
> And remember, Linus wrote git because no other tool was available that
> exactly suited his needs
> 
> Regards,
> 
> Graeme

Best regards,
Marek Vasut