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

[Graeme Russ <graeme.russ@gmail.com>]

Hi All,

On 07/21/2012 11:27 AM, Marek Vasut wrote:
> Dear Tom Rini,
> 
>> On Wed, Jul 18, 2012 at 09:21:40AM +0200, Wolfgang Denk wrote:
>>
>> [snip]
>>
>>> 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...
>>
>> I told Marek on IRC that I don't understand this, given a lot of the
>> things I've made Jenkins do before and that at the end of the day it's
>> $whatever-pass/fail-logic
> 
> Not really, what about the warning-logic ? Aka. I actually need jenkins to do 
> tristate results. How, I didn't figure out.
> 
>> on top of a bash script to do the building and
>> testing.
> 
> So in the end, jenkins is just an executor, bringing in pile of java overhead 
> and possible random breakage. I use MAKEALL in my script, which does exactly 
> what I need ... and even tests MAKEALL ;-)

I don't think a protracted 'tool x' doesn't do this and 'tool y' doesn't do
that is going to get us anywhere.

What we need to do is define exactly what we want out of the patch
management, automated build, etc. tools. We can then see if there are any
tools which already exist which fit our needs. If no existing tools fit,
look at the ones that come closest and investigate what would be required
to get them to a state that they would.

We already know that git is a perfect fit for source code management, and
the mailing list is how we will continue to submit, review and discuss
patches. So that gives a good starting point.

Patch Management:
 - Integrate with existing email work flow. It must pick up patches from
   the mailing list, and any output it generates must get posted to the
   mailing list
 - Reliably track revisions of patches (mark superseded version as such)
 - Automatically run sanity checks (checkpatch, test apply, etc.)
 - Track which repo patches below to
 - Rerun sanity checks on unapplied patches when new patches are applied
   to the associated repo
 - Track patch pre-requisite requirements (need to specify such requirments
   in the patch itself)
 - Track ack'd, nack'd, tested, etc, posted to the mailing list
 - Group multi-patch sets and retain the 0/x patch as it usually contains
   relevant information

Automatic Build:
 - Nightly MAKEALL with output sent to mailing list (only need to run if a
   new patch has been applied)
 - MAKEALL against each repo
 - Automatic build test of patches which pass through the sanity checks of
   the patch management tool. This one is really tricky as a MAKEALL for
   each patch posted to the ML is going to require too many CPU cycles.
   We need a way to determine what configurations a particular patch is
   going to impact and only test against them

Regards,

Graeme