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.