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

[Tom Rini]

On Sat, Jul 21, 2012 at 02:28:45PM +1000, Graeme Russ wrote:

[snip]
> 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.

Agreed, even if I did just reply to Marek :)

> 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

Also track which maintainer(s) a patch belongs to and allow for people
to opt-in to some notice about patches being assigned to them.

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

I would phrase the last one a little differently.  Allow a job to be
submitted that consists of repository X and patches 1-N.  For a given
repository we can say here's the full and representative short build
list of targets.

-- 
Tom