Dear Graeme Russ,
Hi All,
Here's a quick-and-dirty specification for a patch tracking tool...
And here comes our RMK of U-Boot world, the philosopher ;-)
PatchTrack is designed to help alleviate some of the load from custodians manging a email based work flow accepting patches from a large community of contributors
Functionality:
- Monitor an electronic mailing list, extracting patches as they are posted to the list
- Group patchsets that are posted using x/y style numbering. The patches within the set are grouped under the 0/y patch
- Run arbitrarily defined stand-alone sanity checks on each patch. For example, the 'checkpatch' script can be run to check that each incoming patch obeys the style rules of the project
- Associate each patch with a git repository. Association is determined by tags in the patch subject header
- Maintain the revision history of each patch
- Maintain community comments sent to the mailing list for each patch
- Collect Ack'd, Nack'd, Tested, etc. community feedback (the feedback tags are configurable)
- Maintain a 'patch stack' of unapplied patches for each configure repository. The patch stack is maintained as a 'first in, first served' list of patches
- Test that each patch stack applies to the HEAD of the associated git repository
But if you stack the patches, they tend to interfere with each other ... so you might also want to try applying them in the order they arrived or something. But hey, it's 6:20 am in here, don't expect too constructive comment now.
- Re-test that the patch stack applies whenever the HEAD of the associated git repository changes
Yup, sounds very nice and about what we need. Leaving out the build testing was good idea, though working it in later might be necessary.
Interface: The primary interface to PatchTrack is emails extracted from a configured mailbox.
I told you, emails can be forged.
PatchTrack also provides a web-based interface which allows a user to visualise the patch stack for each repository. For each configured repository, the web interface will display associated patches in chronologically ordered rows. Each row is a single patch. patch sets are grouped together using the timestamp of the fist patch. The following information is displayed in each row:
- Patch name/subject
- Author
- Number of received Ack, Nack, Tested, etc. feedbacks
Patchwork can be tweaked to do this, right?
The colour of each row indicates the 'quality' of the patch:
- Red indicates the patch does not apply cleanly. Red patches are not actually in the patch stack but are displayed for completeness
- Orange indicates that the patch does apply but has failed one or more of the configured sanity checks
- Yellow indicates that the patch applies and passed all configured sanity checks
Why not make it "yellow" -- patch has warnings ; "green" -- patch passed checks ; <blue?> -- patch is frozen (aka. accepted)
- Green indicates that the patch has been accepted by a maintainer. All green patches are placed at the top of the stack (i.e. they are always applied first) in order of acceptance (not submission order)
- White indicates that the patch has been applied to the repository
Clicking on any row will expand the row (clicking again will collapse the row). An expanded row displays the following information:
- Ack'd, Nack'd, Tested, etc. tags
- Sanity check results
- Patch apply result
- Comments
- Patch body
The web interface will provide an authenticated login. When a maintainer of a repository is logged in, they can:
- Reject a patch, removing it from the patch stack entirely
- Accept a patch. When a patch is accepted, PatchTrack will check that the patch applies cleanly to the HEAD of previously accepted patches
- Apply the top 'x' accepted patches the git repository
- Purge applied patches from PatchTrack
Mm mm ... I like this, do you plan to hack on it? :)
Best regards, Marek Vasut