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

Tom Rini
2012-07-23T16:49:09Z

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