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

[Wolfgang Denk]

Dear Graeme,

In message <5005562E.6070903 at gmail.com> you wrote:
> 
> I think U-Boot has reached the point that purely manual patch management is
> not longer cutting the mustard.

100% agreed.  The problem I see is that we haven't found a tool that
provides the needed interfaces to deal with the amount of patches we
have to handle.

Patchwork has a number os serious problems, as I see it:

- It chokes on a lot (or all?) base64 encoded messages that have
  special charactes in the comitter's names (and/or the commit
  message).  In my opinion it renders the tool more or less
  worthless if you cannot rely that it really covers all patches.

- Our main communication is e-mail based, and this has proven to be a
  very efficient way to do the work we have to do - so we need a tool
  that integrates with this tooling.  When I send an e-mail reply to a
  submitter requesting changes to his patch, I want to be able to use
  the same e-mail message to automatically change the patch status in
  PW.  Unfortunately, no such way exists.

- PW identifies patches based on the hash value over the commit body.
  It appears to search oldest first, and stop on first hit.  This
  causes problems with resubmitted patches.  Assume someone submits a
  patch, an I as for changes in the commit message (better documen-
  tation, etc.); I mark the patch as changes requested.  The submitter
  sends  a new version, with improved commit message.  I mark the old
  patch as "superseded", and the new one as "under review".  When I
  finally want to apply the new patch, I usually do this from my
  mailer, which results in using the hash to locate the patch. Result:
  1) The old patc gets applied instead of the new one.
  2) The old patch gets mared as applied, the new one remains in
     "under review" state.

These are just the most aggravating bugs; I've discussed all of these
on the PW mailing list, and with JK.  Nothing happened since.

For me PW is more or less dead.

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

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

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
An expert is a person who avoids the small errors while  sweeping  on
to the grand fallacy.