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

Marek Vasut
2012-07-21T14:46:51Z

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