[U-Boot] RFC - PatchTrack Specification

[Marek Vasut]

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