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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
